Smart contract-managed decentralized lending processes using collateral tokens

ABSTRACT

A loan process smart contract manages a collateralized loan process for a loan against a collateralized item, the collateralized loan process including tokenizing and locking a collateral token that tokenizes the collateral item, selecting a loan process workflow based on a type of collateralized item, monitoring terms of the loan, and detecting an unlocking event of the loan for unlocking the collateral token.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.17/703,507, filed Mar. 24, 2022, which is a bypass continuation of PCTInternational Application No. PCT/US2020/052728, filed Sep. 25, 2020,which claims priority to U.S. Provisional Application No. 62/906,211,filed on Sep. 26, 2019. The entire disclosure of each of the aboveapplications is incorporated herein by reference.

FIELD

The present disclosure relates to decentralized lending systems andmethods that leverage smart contracts and distributed ledgers, such asblockchains, to provide a trustless or substantially trustlesscollateralized lending ecosystem.

BACKGROUND

Conventional e-Commerce processes involve unnecessary friction. Theseprocesses were typically designed around use cases in which a purchaserplaces an order knowing exactly what they want, how they are going topay for it, where it is going to go, who it is for, and that they wantit as soon as possible. Conventional e-commerce does not allow for muchflexibility in these buying decisions. For example, a user wishing topurchase a gift for someone typically makes a purchase via a website ormobile application, enters the intended recipient's known address(regardless of whether the recipient typically receives packages at theknown address), and pays for the gift. The gift is then immediately sentto the recipient, regardless of whether the recipient is available toreceive the package. Accordingly, there is a need in the art for ane-commerce platform with greater flexibility around all facets of atransaction including, but not limited to, purchase selection, payment,transfer of possession, and location and timing of delivery.

Meanwhile, virtual items have become increasingly popular, such as invideo games, where skins, weapons, tools, and many other items arepurchased and traded among players. Virtual items, like other digitalitems, can be possessed, used and transferred without the sameconstraints on transportation, delivery and storage that are involvedfor physical items. However, the value of a virtual item can beephemeral, as creators can potentially create an unlimited number ofcopies, rendering initially rare items much less valuable. A need existsfor a platform with methods and systems that provide both theflexibility and convenience of virtual item transactions and thereliability and value of physical item transactions.

In most loan scenarios, a borrower may wish to obtain a loan from alender. Typically, a lender may require collateral to secure the loanbefore agreeing to the terms. Traditionally, a borrower could go to aphysical pawn shop, where a pawn shop owner/agent is responsible forauthenticating the item, appraising the item, storing the item safely,and loaning the funds and in exchange, the borrower provides the item ascollateral. In this arrangement, both the lender and the borrower aresimultaneously put in disadvantaged positions. The lender must trustthat the pawnshop owner/agent gives a fair appraised value to acollateral item and will store the collateral item in good faith, whilethe pawnshop agent must trust that the item is authentic and that thepawnshop will be able to liquidate the collateral item should theborrower default on the loan. These dilemmas result in the borrowerbeing given a much lower appraised value on a collateral item and thepawn shop agent taking on an increased amount of risk, the combinationof which results in lower loan amounts and higher interest rates/loancosts. As such, pawn shops are viewed as last resort loan sources andborrowers are often taken advantage of by opportunistic loan sharksmasquerading as pawn shops. As such, there is a need for decentralizedlending systems that provide a trustless or substantially trustlesslending ecosystems.

SUMMARY

Provided herein are systems and methods for facilitating decentralizedloan processes with a smart contract architecture. In embodiments, thedecentralized loan process is executed in a series of stages, includingan authentication stage where a collateral item is authenticated, anappraisal stage where the collateral item is appraised, and asafekeeping stage where the item is physically secured in a safekeepingfacility. In embodiments, the collateral item is “tokenized,” such thatthe collateral item can remain in safekeeping but the ownership rightscan be transferred using a digital collateral token that represents thephysical collateral item. In embodiments, a set of smart contractsmanage the loan process, including one or more of the loan processstages.

According to some embodiments of the present disclosure, a method isdisclosed. The method includes receiving, by one or more processingdevices, a request to initiate a loan process from a borrower device,the request indicating a collateral item, wherein the collateral item isa tangible item. The method also includes generating, by the one or moreprocessing devices, a virtual representation of the collateral item,wherein the virtual representation includes at least one of adescription of the collateral item and one or more media contents thatrespectively depict at least a portion of the collateral item. Themethod further includes generating, by the one or more processingdevices, a collateral token corresponding to the collateral item basedon the virtual representation of the collateral item, wherein thecollateral token is a digital token that is stored on a distributedledger that is distributed across a set of node devices. The methodfurther includes instantiating, by the one or more processing devices, aloan process smart contract instance that includes computer-readableinstructions that are configured to manage a loan process in accordancewith a loan process workflow, wherein the loan process smart contractinstance is executed by the set of node devices that store thedistributed ledger. The loan process smart contract instance isconfigured to instantiate a loan smart contract that includescomputer-readable instructions that are configured to receive a loanagreement notification indicating one or more loan term parameters of aloan that was agreed to by a lender and the borrower and to managerepayment of a loan based on the one or more loan term parameters. Thecollateral token is locked in an escrow account stored on thedistributed ledger until the loan smart contract instance determinesthat the loan has been fully repaid or the loan is in a default state.

In embodiments, the computer-readable instructions of the loan processsmart contract instance are further configured to instantiate anauthentication smart contract instance that includes computer readableinstructions that are configured to manage an authentication task thatis performed by an authenticator to authenticate the collateral item andto issue an authentication notification upon confirming that theappraisal task has been completed. In some of these embodiments, theloan process smart contract instance instantiates the authenticationsmart contract instance in accordance with the loan process workflow. Insome of these embodiments, the loan process workflow is defined in asystem-level governance document that is stored on the distributedledger, wherein the system-level governance defines a condition toinitiate the authentication task. In some embodiments, the loan processsmart contract instance instantiates the authentication smart contractinstance in response to receiving a request notification indicating thatthe borrower has requested to initiate the loan process. In someembodiments, the computer-readable instructions of the loan processsmart contract instance are further configured to: receive anauthentication report from an authenticator device of the authenticator,wherein the authentication report includes an authentication opinion ofthe authenticator that indicates an authentication state, includingwhether the authenticator has deemed the collateral item authentic ornot authentic. In some of these embodiments, the authentication reportfurther includes supporting documentation provided by the authenticatorin support of the authentication opinion. In some of these embodiments,the authentication report further includes one or more verificationsissued by one or more respective secondary authenticators, wherein eachverification indicates that a respective secondary authenticatorconfirmed the authentication opinion. In some of these embodiments, theauthentication report is generated from a form template that is definedin accordance with an authentication stage-level governance that definesa set of rules and regulations associated with performance of theauthentication task. In some of these embodiments, the authenticationstage-level governance defines an authentication task workflow, whereinthe authentication task workflow includes one or more conditions thatmust be met to complete the authentication task and trigger a next stagein the loan process workflow to which the loan process adheres. In someof these embodiments, the authentication stage-level governance is atleast partially defined by an authentication guild to which theauthenticator is a guild member. In some of these embodiments, theauthentication guild includes a plurality of different specializedauthentication guilds, wherein each specialized authentication guildspecializes in authenticating a respective type of collateral item. Insome of these embodiments, the plurality of different specializedauthentication guilds includes at least a subset of the groupcomprising: a watch authentication guild that specializes inauthenticating watches, a shoe authentication guild that specializes inauthenticating shoes, a handbag authentication guild that specializes inauthenticating handbags, an art authentication guild that specializes inauthenticating works of art, a sports memorabilia authentication guildthat specializes in authenticating sports memorabilia, a toyauthentication guild that specializes in authenticating collectibletoys, a jewelry authentication guild that specializes in authenticatingjewelry, a clothing authentication guild that specializes inauthenticating designer clothing, an instrument authentication guildthat specializes in expertise authenticating musical instruments, arecord authentication guild that specializes in authenticating rare orcollectible records, a wine authentication guild that specializes inexpertise authenticating units (e.g., barrels or bottles) of wine, awhiskey authentication guild that specializes in authenticating units(e.g., barrels or bottles) of whiskey, and an automobile authenticationguild that specializes in authenticating limited edition automobiles. Insome of these embodiments, the authenticator belongs to a specializedauthentication guild of the different specialized authentication guilds.In some of these embodiments, the authenticator is assigned theauthentication task based on the specialized authentication guild towhich the authenticator belongs and an item type of the collateral item.In some embodiments, the authentication stage-level governance definesan authentication smart contract from which the authentication smartcontract instance was instantiated. In some embodiments, theauthentication smart contract instance initiates an escrowing of anamount of currency tokens and/or tokenized tokens from an account of theauthenticator to the escrow account in response to the authenticationreport indicating that the authenticator deemed the collateral item tobe authentic. In some embodiments, at least a portion of the escrowedamount is held in escrow until the loan process is complete. In someembodiments, the authentication smart contract instance outputs theauthentication notification to the loan process smart contract inresponse to receiving the authentication report from the authenticatordevice, wherein the authentication notification causes the loan processsmart contract instance to initiate an appraisal stage of the loanprocess. In some embodiments, the authentication smart contract instanceis further configured to: generate a data block containing theauthentication report and a cryptographic hash value that is generatedbased at least in part on the authentication report; and write the datablock to the distributed ledger. In some embodiments, a rating of theauthenticator is updated based on an outcome associated with theauthentication task.

In embodiments, the computer-readable instructions of the loan processsmart contract instance are further configured to instantiate anappraisal smart contract instance that includes computer-readableinstructions that are configured to manage an appraisal task that isperformed by an appraiser to determine an appraisal value of thecollateral item and to issue an appraisal notification upon confirmingthat the appraisal task has been completed. In some of theseembodiments, the loan process smart contract instantiates the appraisalsmart contract instance in accordance with the loan process workflow. Insome of these embodiments, the loan process workflow is defined in asystem-level governance document that is stored on the distributedledger, wherein the system-level governance defines a condition toinitiate the appraisal task. In some embodiments, the loan process smartcontract instantiates the appraisal smart contract instance in responseto receiving an authentication notification indicating that anauthenticator has authenticated the collateral item and deemed thecollateral item as authentic. In some embodiments, the computer-readableinstructions of the loan process smart contract instance are furtherconfigured to receive an appraisal report from an appraiser device ofthe appraiser, wherein the appraisal report includes a valuation of thecollateral item including at least one of an appraised value of thecollateral item and a liquidation value of the collateral item. In someof these embodiments, the appraisal report further includes one or moreof a physical condition of the item, a new or used condition of thecollateral item, a working condition of the collateral item, prices ofprevious sales of similar items, and a bluebook valuation of similaritems. In some embodiments, the appraisal report further includes one ormore verifications issued by one or more respective secondaryappraisers, wherein each verification indicates that a respectivesecondary appraiser confirmed the appraisal value. In some embodiments,the appraisal report is generated from a form template that is definedin accordance with an appraisal stage-level governance that defines aset of rules and regulations associated with performance of theappraisal task. In some embodiments, the appraisal stage-levelgovernance defines an appraisal task workflow, wherein the appraisaltask workflow includes one or more conditions that must be met tocomplete the appraisal task and trigger a next stage in the loan processworkflow. In some of these embodiments, the appraisal stage-levelgovernance is at least partially defined by an appraisal guild to whichthe appraiser is a guild member. In some of these embodiments, theappraisal guild includes a plurality of different specialized appraisalguilds, wherein each specialized appraisal guild specializes inappraising a respective type of collateral item. In some embodiments,the plurality of different specialized appraisal guilds includes atleast a subset of the group comprising: a watch appraisal guild thatspecializes in appraising watches, a shoe appraisal guild thatspecializes in appraising shoes, a handbag appraisal guild thatspecializes in appraising handbags, an art appraisal guild thatspecializes in appraising works of art, a sports memorabilia appraisalguild that specializes in appraising sports memorabilia, a toy appraisalguild that specializes in appraising collectible toys, a jewelryappraisal guild that specializes in appraising jewelry, a clothingappraisal guild that specializes in appraising designer clothing, aninstrument appraisal guild that specializes in expertise appraisingmusical instruments, a record appraisal guild that specializes inappraising rare or collectible records, a wine appraisal guild thatspecializes in expertise appraising units (e.g., barrels or bottles) ofwine, a whiskey appraisal guild that specializes in appraising units(e.g., barrels or bottles) of whiskey, and an automobile appraisal guildthat specializes in appraising limited edition automobiles. In some ofthese embodiments, the appraiser belongs to a specialized appraisalguild of the different specialized appraisal guilds. In someembodiments, the appraiser is assigned the appraisal task based on thespecialized appraisal guild to which the appraiser belongs and an itemtype of the collateral item. In some embodiments, the appraisalstage-level governance defines an appraisal smart contract from whichthe appraisal smart contract instance was instantiated. In someembodiments, the appraisal smart contract instance initiates anescrowing of a monetary amount of currency tokens and/or tokenizedtokens from an account of the appraiser to the escrow account inresponse to receiving the appraisal report, wherein the monetary amountof currency tokens and/or tokenized tokens is equal to or less than theappraisal value. In some embodiments, at least a portion of the escrowedamount is locked in the escrow account until the loan process iscomplete. In some embodiments, the appraisal smart contract instanceoutputs the appraisal notification to the loan process smart contract inresponse to receiving the appraisal report from the appraiser device,wherein the appraisal notification causes the loan process smartcontract instance to initiate a safekeeping stage of the loan process.In some embodiments, the appraisal smart contract instance is furtherconfigured to generate a data block containing the appraisal report anda cryptographic hash value that is generated based at least in part onthe appraisal report; and write the data block to the distributedledger. In some embodiments, a rating of the appraiser is updated basedon an outcome associated with the appraisal task.

In embodiments, the computer-readable instructions of the loan processsmart contract instance are further configured to instantiate asafekeeping smart contract instance that includes computer-readableinstructs that are configured to manage a safekeeping task performed bya safekeeper to securely store the collateral item during at least aportion of the loan process and issue a safekeeping notification uponconfirming that the safekeeping task has been completed. In someembodiments, the loan process smart contract instantiates thesafekeeping smart contract instance in accordance with the loan processworkflow. In some of these embodiments, the loan process workflow isdefined in a system-level governance document that is stored on thedistributed ledger, wherein the system-level governance defines acondition to initiate the safekeeping task. In some embodiments, theloan process smart contract instance instantiates the safekeeping smartcontract instance in response to receiving an appraisal notificationindicating that an appraiser has appraised the collateral item. In someembodiments, the computer-readable instructions of the loan processsmart contract instance are further configured to: receive a safekeepingreport from a safekeeper device of the safekeeper, wherein thesafekeeping report includes a verification that the item is stored in afacility associated with the safekeeper and includes indication of anyvisible damage observed by the safekeeper when the collateral item wasreceived. In some embodiments, the safekeeping report further includessupporting documentation provided by the safekeeping as proof ofcompletion of the safekeeping task. In some embodiments, the safekeepingreport further includes photo documentation of the visible damageobserved by the safekeeper when the collateral item was received by thesafekeeper. In some embodiments, wherein the safekeeping report isgenerated from a safekeeping form template that is defined in accordancewith a safekeeping stage-level governance that defines a set of rulesand regulations associated with performance of the safekeeping task. Insome embodiments, wherein the safekeeping stage-level governance definesa safekeeping task workflow, wherein the safekeeping task workflowincludes one or more conditions that must be met to complete thesafekeeping task and trigger a next stage in the loan process workflow.In some embodiments, the safekeeping stage-level governance is at leastpartially defined by a safekeepers guild to which the safekeeper is aguild member. In some embodiments, the safekeeping stage-levelgovernance defines a safekeeping smart contract from which thesafekeeping smart contract instance was instantiated. In someembodiments, the safekeeping smart contract instance initiates anescrowing of a monetary amount of currency tokens and/or tokenizedtokens from an account of the safekeeping to the escrow account inresponse to receiving the safekeeping report, wherein the monetaryamount of currency tokens and/or tokenized tokens is equal to or lessthan an appraisal value determined by an appraiser of the collateralitem. In some embodiments, at least a portion of the escrowed amount islocked in the escrow account until the loan process is complete. In someembodiments, the safekeeping smart contract instance outputs thesafekeeping notification to the loan process smart contract in responseto receiving the safekeeping report from the safekeeper device, whereinthe safekeeping notification causes the loan process smart contractinstance to initiate the generation of the collateral token. In someembodiments, the safekeeping smart contract instance is furtherconfigured to generate a data block containing the safekeeping reportand a cryptographic hash value that is generated based at least in parton the safekeeping report and write the data block to the distributedledger. In some embodiments, a rating of the safekeeping is updatedbased on an outcome associated with the safekeeping task. In someembodiments, the safekeeper device provides one or more images of thecollateral item that are used to generate the virtual representation ofthe collateral item. In some embodiments, the safekeeping smart contractinstance is configured to execute a redemption workflow after thecollateral token is unlocked from the escrow account. In some of theseembodiments, the redemption workflow results in a redeemer of thecollateral token taking possession of the collateral item from thesafekeeper.

In embodiments, the method further includes the loan smart contractinstance is configured to initiate a liquidation process in response todetermining that the loan is in a default state. In some embodiments,the collateral token is transferred to a buyer that purchases thecollateral token during the liquidation event, such that the buyerredeems the collateral token to take possession of the collateral itemfrom a safekeeper that holds the collateral item for safekeeping.

In embodiments, the loan smart contract instance configured to initiatea transfer of the collateral token from the escrow account to an accountof the borrower upon determining that the loan has been fully repaid. Insome of these embodiments, the collateral token is transferred to theaccount of the borrower from the escrow account by updating ownershipdata that defines a current owner of the collateral token such that theownership data includes an address of the account of the borrower on thedistributed ledger.

In embodiments, the loan term parameters include a loan length and aloan amount. In some embodiments, the loan smart contract is configuredto determine a loan repayment schedule based on the loan length and theloan amount, and wherein the loan is considered to be in a default stagewhen a pre-defined amount of payments are not paid in accordance withthe payment schedule.

In embodiments, the loan process workflow including an authenticationstage that defines an authentication task that is performed by anauthenticator, an appraisal stage that defines an appraisal task that isperformed by an appraiser, and a safekeeping stage that defines asafekeeping task that is performed by a safekeeper. In some embodiments,the authentication stage, the appraisal stage, and the safekeeping stageare executed before the collateral token is generated. In someembodiments, the loan instance smart contract instance facilitatesassigning rewards to the authenticator, the appraiser, and thesafekeeper in response to the loan process completing.

In embodiments, the change of the state of the loan that triggers theunlocking of the collateral token is at least one of: the loan enteringa fully repaid state, the loan entering a default state and thecollateral item being successfully liquidated, and a state of repaymentupon which collateral is no longer required as defined in the loanagreement.

In embodiments, the collateral token wraps the virtual representation ofthe collateral item.

In embodiments, the loan smart contract is configured to determine aloan repayment schedule based on a loan length and a loan amount of theloan as defined in the loan term parameters, and wherein the loan isconsidered to be in a default stage when a pre-defined amount ofpayments are not paid in accordance with the payment schedule.

In embodiments, the loan process workflow includes an authenticationstage that defines an authentication task that is performed by anauthenticator, an appraisal stage that defines an appraisal task that isperformed by an appraiser, and a safekeeping stage that defines asafekeeping task that is performed by a safekeeper, wherein theauthentication stage, the appraisal stage, and the safekeeping stage areexecuted before the collateral token is generated. In some of theseembodiments, the loan instance smart contract instance facilitatesassigning rewards to the authenticator, the appraiser, and thesafekeeper in response to the loan process completing.

In embodiments, the collateral item is a tangible item. In embodiments,the change of the state of the loan is at least one of: the loanentering a fully repaid state, the loan entering a default state and thecollateral item being successfully liquidated, and a state of repaymentupon which collateral is no longer required as defined in the loanagreement.

In embodiments, the distributed ledger is a blockchain.

A more complete understanding of the disclosure will be appreciated fromthe description and accompanying drawings and the claims, which follow.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a betterunderstanding of the disclosure, illustrate embodiment(s) of thedisclosure and together with the description serve to explain theprinciple of the disclosure. In the drawings:

FIG. 1 is a schematic illustrating an example environment of atokenization platform according to some embodiments of the presentdisclosure.

FIG. 2 is a schematic illustrating an example marketplace systemaccording to some embodiments of the present disclosure.

FIG. 3 is a schematic illustrating an example ledger management systemaccording to some embodiments of the present disclosure.

FIG. 4 is a schematic illustrating an example transactions systemaccording to some embodiments of the present disclosure.

FIG. 5 is a schematic illustrating an example intelligence andautomation system according to some embodiments of the presentdisclosure.

FIG. 6 is a schematic illustrating an example analytics and reportingsystem according to some embodiments of the present disclosure.

FIG. 7 is a user interface displaying tokens within a wallet, accordingto some embodiments of the present disclosure.

FIG. 8 is a schematic illustrating an example set of components of atokenization platform according to some embodiments of the presentdisclosure.

FIG. 9 is a flowchart showing a technique for tokenizing items accordingto some embodiments of the present disclosure.

FIG. 10 is a flowchart showing a technique for transferring tokens usinga digital marketplace according to some embodiments of the presentdisclosure.

FIG. 11 is a flowchart showing a technique for transferring tokensbetween wallets via a keyboard interaction according to some embodimentsof the present disclosure.

FIG. 12 is a flowchart showing a technique for redeeming tokensaccording to some embodiments of the present disclosure.

FIG. 13 is a flowchart showing a technique for collateralization and/orsecuritization according to some embodiments of the present disclosure.

FIG. 14 is a flowchart showing a technique for item authenticationaccording to some embodiments of the present disclosure.

FIG. 15 is a flowchart showing a technique for rendering VR environmentsaccording to some embodiments of the present disclosure.

FIG. 16 is a flowchart showing a technique for facilitating transactionsusing a distributed ledger with a side chain of blocks according to someembodiments of the present disclosure.

FIG. 17 is a flowchart showing a technique for facilitating useracquisition according to some embodiments of the present disclosure.

FIG. 18 is a flowchart showing a technique for managing mystery boxesaccording to some embodiments of the present disclosure.

FIG. 19 is a flowchart showing a technique for video-game integrationaccording to some embodiments of the present disclosure.

FIG. 20 is a schematic illustrating an example ecosystem of adecentralized lending system according to some embodiments of thepresent disclosure.

FIG. 21 is a schematic illustrating an example of guilds, sub-guilds,and various types of governances that govern various stages of adecentralized loan process according to some embodiments of the presentdisclosure.

FIG. 22 is a flow chart illustrating an example set of operations of amethod for performing an authentication workflow according to someembodiments of the present disclosure.

FIG. 23 is a flow chart illustrating an example set of operations of amethod for performing an appraisal workflow according to someembodiments of the present disclosure.

FIG. 24 is a flow chart illustrating an example set of operations of amethod for performing a safekeeping workflow according to someembodiments of the present disclosure.

FIG. 25 is a flow chart illustrating an example set of operations of amethod for performing a loan workflow according to some embodiments ofthe present disclosure.

FIG. 26 is a flow chart illustrating an example set of operations of amethod for performing a pre-loan liquidation workflow according to someembodiments of the present disclosure.

FIG. 27 is a diagram illustrating a set of stages of a loan processworkflow according to some embodiments of the present disclosure.

FIG. 28 is a diagram illustrating a set of stages of a loan processworkflow according to some embodiments of the present disclosure.

FIG. 29 is a diagram illustrating a set of stages of a loan processworkflow according to some embodiments of the present disclosure.

FIG. 30 is a diagram illustrating a set of stages of a loan processworkflow according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

The combination of blockchain technology and smart contracts has beenproposed for use in systems and methods for implementing a variety oftransactions in a way that automates much of the transaction whilepreserving and respecting the legal constraints on such automation. Oneof the limitations on automation of such systems is the existence ofjurisdiction specific rules and processes for (i) creating legallybinding contracts between parties, and (ii) exchanging property in a waythat transfers ownership interests, security interests, or other similarinterests in a legally binding manner.

Some of the proposed systems depend on the future implementation ofblockchain technology for the legal systems of record for suchtransfers, including real property records, Uniform Commercial Codefiling systems, and other similar systems. This transition is dependenton governmental bodies creating and adopting blockchain-basedrecord-keeping systems. For example, real property records in the UnitedStates are typically maintained at the county-level by an electedofficial, and documents are subject to specific rules regarding formatand methods of submission to the record. Each such official utilizestheir own systems to accept and record documents. Adoption of ablockchain-based record-keeping system would thus require eachjurisdiction to select and implement such a system. This process cantake years even once the technology for such systems is developed andavailable for implementation. The willingness of jurisdictions to adoptnew technologies also may vary widely, and so it is impossible todetermine when all jurisdictions will migrate to a blockchain-basedsystem, if ever.

Since the benefits of blockchain technologies should not wait untilgovernmental record keepers decide to begin to implement systems basedon the technology, hybrid systems that provide the benefits ofblockchain technology but also interface with existing record-keepingand other legal systems are necessary to bridge the gap. Systems likethose disclosed herein provide the benefits of blockchain to users ofthe system, interface with existing legal systems and methods, and willbe easier to migrate to a full block-chain based system if they becomeavailable.

The distributed ledger transaction systems and methods described hereinutilize distributed ledger technology (e.g., blockchain technology) incombination with smart contracts to allow users to negotiate, document,and/or execute a variety of different transactions. According to someembodiments, the different transactions include securitizeddecentralized loan transactions. These loan transactions include loantransactions that are secured by traditional types of collateral and/orby digital assets.

In general distributed ledger technology forms the basis forcryptocurrencies that are rapidly expanding in application and adoption.Such cryptocurrencies augment or replace existing payment methodologiessuch as cash, but also provide a decentralized system for processingtransfers of the cryptocurrency. The basis for the distributedledger/blockchain technology is a linked list of data blocks. Each blockcontains a link to the prior block in the chain and encrypted data. Insome implementations of a distributed ledger, the encrypted data mayinclude transaction data documenting the exchange of a digital currency,software such as an executable digital contract, and data associatedwith the use of a digital contract by specific parties, although it mayalso include other types of data as described in further detail below.The data in each block in the distributed ledger includes a hash of theprevious block in the chain as a means of identifying and preventingattempts to modify prior blocks in the distributed ledger.

In many implementations of distributed ledger technology, the managementand extension of the distributed ledger is decentralized and distributedover computer systems operated by numerous unaffiliated entities whocontribute their computing power to the system. These distributedcontributors provide the infrastructure of the distributed ledger systemby storing copies of the distributed ledger, and performing thealgorithms necessary to process transactions, deploy them into newblocks on the distributed ledger, and distribute those blocks to otherparts of the system. In some distributed ledger implementations thecontributors are compensated for this service by receiving a feedenominated in a cryptocurrency in return for the processing of a newblock in the distributed ledger. An important aspect of distributedledger security is that it is difficult to modify blocks after they havebeen added to a distributed ledger and accepted into the main branch,although distributed ledgers do have temporary competing branches.

The distributed ledger technology has been enhanced by the concept of“smart contracts”. Smart contracts are executable computer programs thatare compiled into the data in a block in a distributed ledger by thedevelopers of the smart contract. Once a smart contract has beendeployed into a distributed ledger, other users of the distributedledger may execute the smart contract with confidence that it has notbeen modified by a malicious third party. These executable computerprograms are referred to as “smart contracts” because they may be usedto represent and implement agreements between various parties regardingthe transfer of digital currency and other types of assets, however,they do not have to represent contractual arrangements. A softwaredeveloper develops the smart contract by writing program code using ascripting language such as JavaScript, Solidity, or other scriptinglanguages, or an object coding language, such as Java, or a machinecoding language such as C or C++. When a “smart contract” is deployedinto a distributed ledger, the program code is processed into a block byone of the contributors to the system just as any other transaction onthe distributed ledger, and typically a fee is paid to the nodecontributor who compiles the contract/program. The process of deployingthe smart contract may include compiling the program code into bytecode,object code, binary code, or some other executable form. When the smartcontract is successfully deployed into the block chain it is assigned anaddress just as any other distributed ledger transaction. This addressis used to access the smart contract and execute the functionalityprovided in it. Typically, an Application Binary Interface (ABI)information, similar to an application programming interface, isprovided to a user of the contract, or the software that interfaces withthe contract (such as a wallet application) so that the user caninteract with the various functions of the smart contract. The ABIdescribes the various functions and methods provided as part of thesmart contract so that they can be accessed by the user or the user'ssoftware.

A contract/program that has been deployed into the distributed ledgermay then be used by anyone who has the address of the contract on thedistributed ledger. Executing the contract, or a portion of it, does notnecessarily incur fees unless updates to the distributed ledger arerequired as part of that step in the contract. If the contract/programis properly implemented many different users may utilize thecontract/program simultaneously to govern their own specific agreementsor transactions.

In embodiments, a smart contract/program may have multiple steps thatare executed or completed by different parties to the contract. Forexample, a contract/program may be invoked by a first party to make anoffer to a second party or a group of potential contracting parties byinstantiating a copy of a certain contract. The second party (or one ofthe group) may respond by “signing” that instance of the contract. Theprocess of “signing” the contract may comprise invoking a programmaticmethod defined as part of the contract. Some contracts may provide formultiple parties, such as buyer, seller, lender, borrower, escrow agent,authenticator, appraiser, and/or the like, all of whom may independentlyinteract with a particular instance of a smart contract to sign it, orto take other actions associated with a specific type of smart contract.

Smart contracts are well suited to contracts that involve digital assetsor that may be completely executed via programmatic interactions betweenthe contracting parties, the distributed ledger, digital assets, andresources on the internet or otherwise connected digitally to thecontract. For example, smart contracts may be able to automaticallytransfer control and ownership of digital assets or transfer moneybetween PayPal or bank accounts via ACH or other electronic paymentsystems. Application programming interfaces provided by the externalsystems provide methods for a digital contract to execute actualtransfers of assets or funds between parties without non-programmaticprocesses.

Smart contracts are not so readily able to fully implement agreementsthat involve tangible assets, such as real estate, personal property,and other types of assets that are subject to the control ofgovernmental or private registration systems. These registration systemsare often paper-based or, if electronic, are not designed forprogrammatic interaction by third parties. Examples of such systemsinclude real estate ownership records, personal property records forassets that are titled, Uniform Commercial Code records, patent andtrademark registration databases, and others. Many of these systems maybe partially digital but are lacking in a programmatic interface for asmart contract to interact with the system in a completely automatedmanner or are highly proprietary in nature. Other systems may befractured into many jurisdictions with their own separate filingsystems, so that a single smart contract would not be functional acrossall relevant systems. For example, Uniform Commercial Code filings aretypically handled by differing systems across different statejurisdictions, and a smart contract would need to implement varyinginterfaces to be able to handle transactions outside of a singlejurisdiction and depending on whether such interfaces were available fora given jurisdiction.

One type of contract that has not been able to be fully executed via theprogrammatic functions of a smart contract/program is a secured lendingtransaction. While many parts of such transactions may be completed viainteractions between parties and the smart contract, the transfer oftitle and possession, and the creation of security interests for thebenefit of lenders, among other aspects of the transaction, are notreadily adapted to completion via the smart contract. According toembodiments of the present disclosure, a decentralized lending systemthat incorporates a set of distributed ledgers and a set of smartcontracts that facilitates is created to support one or more types ofsmart contracts. In various embodiments of the system, the set ofdistributed ledgers may host a variety of types of smart contracts, suchas guild governance smart contracts, authenticator smart contracts,appraisal smart contracts, loan smart contracts, and/or other smartcontracts are implemented to support securitized decentralized loanprocesses. The programmatic smart contracts are compiled intodistributed ledger(s) and reside at certain addresses within arespective block in the distributed ledger(s). Users may utilize thesesmart contracts by invoking the address and methods or functionsassociated with the smart contract. For example, an example loancontract may have methods for a loan request, loan approval, collateralassignment, payment authorization, and/or other similar functionsnecessary to the formation and execution of a loan, the provision ofcollateral as security, and repayment of the loan according to itsterms.

Continuing the loan contract example, when a user utilizes a smartcontract and invokes a method or function of that contract, the user maysubmit parameters and other information to the smart contract that arespecified by a particular method or function. The smart contract maythem programmatically execute a selected method or function inaccordance with those parameters. In the case of a loan requestfunction, a loan smart contract may take the parameters received from auser who desires to take out a loan and incorporate that requestinformation into a new block in the blockchain so that potential lenderscan view the request. In some embodiments the loan request might not beincorporated into the distributed ledger but might be stored in adatabase that is programmatically available to potential lenders such asvia a web service.

The present disclosure relates to a tokenization platform that enablesthe creation of virtual representations of items (also referred to as“VIRLs”), such as goods, services, and/or experiences. As used hereinthe term “item” may refer to a digital asset (e.g., gift card, digitalmusic file, digital video file, software, digital photograph, etc.),physical good, digital service (e.g., video streaming subscription),physical service (e.g., chauffer service, maid service, dry cleaningservice), and/or purchased experience (e.g., hotel package, concertticket, airlines ticket, etc.), or any combination thereof. It is notedthat an item may refer to goods that already exist or that can beproduced at a later time. For example, an item may be an unmade pizza orarticle of clothing. A purchaser of such an item may purchase the item,and the item may be produced at a time after the purchase. The termvirtual item may refer to a virtual representation of a merchandiseditem. In creating a virtual representation to an item, many of thepurchase-time decisions required for traditional ecommerce transactionscan be postponed and bifurcated from the transaction itself, therebycreating additional value for the purchaser. For example, a purchasermay wish to order a pair of shoes but is not yet sure when the shoeswill be needed or where the delivery location should be. The purchasermay purchase the virtual representation of the shoes. The virtualrepresentation may be redeemed at a later time, such that the redeemer(e.g., the purchaser or a recipient of a gift) may specify the deliverytime and delivery location when the redeemer so chooses. By creatingvirtual items, new value is created for purchasers or any recipients, asa series of choices that can be put on hold until redemption time.

Furthermore, in conventional ecommerce platforms, there are norecordation mechanisms of an item being transferred between unknownparties that can be checked and trusted. Additionally, there is also noway of storing sensitive financial information without a centralizedentity. Thus in embodiments, the tokenization platform may be configuredto issue electronic tokens (or “tokens”) that are configured to bestored on a cryptographically secure ledger to provide a process bywhich virtual representations allow the transfer of the item betweenunknown parties, while also allowing anyone to check the status of thetoken at any time and trust that it is correct. As used herein, unlessotherwise indicated by context, “cryptographically” indicates use of acryptographic algorithm, such as a hashing algorithm.

The ecommerce platform may be configured to support additional oralternative ecosystems. In embodiments, the tokenization platform isconfigured to support a token-based lending system, whereby lenders maycreate virtual items corresponding to collateral (e.g., jewelry,collectible items, artwork, and the like). The ecommerce platform maytokenize the virtual item and may store the token on a distributedledger. In this way, the loan may be sold and only the token needs to betransferred between lenders. In some embodiments, a smart contract maybe used to manage the loan, possession of the token, and othertransactions corresponding to the loan.

In some embodiments, the tokenization platform is configured toauthenticate real world items. In some of these embodiments, thetokenization platform may enlist subject matter experts to authenticateitems using a virtual representation of the items. A subject matterexpert may provide an authentication report that includes notes for theexpert's underlying opinion. The authentication report may be used todeny or allow an item to be used for collateral or sold on the platform.Additionally, in some embodiments, the authentication reports can beused to train machine learned models, such that the platform may usemachine vision, machine learning, sensors (e.g., scales), and/or othersuitable techniques to authenticate items.

In embodiments, the tokenization platform is configured to support a“mystery box” game. The mystery box game is a game of change, whereusers can win tokens from the mystery box, such that the tokensrepresent items and the tokens can be redeemed, traded, sold, gifted,and the like. In some of these embodiments, the tokenization platformsupports casino-style gaming, whereby the mystery box game may be playedat casinos and other brick and mortar locations.

In embodiments, the tokenization platform is configured to supportin-video game streaming. In some of these embodiments, the tokenizationplatform may provide indicators of tokens to instances of video games,whereby the video game makers can use the tokens in a number ofdifferent ways. For example, tokens may appear in a video game to allowa food delivery service to sell deliverable food in game. In anotherexample, a token may represent a digital item that can be used in thegame, but then later can be redeemed to obtain a real-world itemcorresponding to the digital item.

In embodiments, the tokenization platform may provide a rewards-baseduser acquisition program, whereby users can enlist for referral codes.When the user successfully refers a user to the tokenization platform,the user is rewarded with a token. The token can represent monetarycompensation or an item (e.g., a gift card, a pair of shoes, a musicalbum, a DVD, or the like).

FIG. 1 illustrates an example ecosystem of a tokenization platform 100(or the “platform”) according to some embodiments of the presentdisclosure. The environment includes the platform 100, node computingdevices 160, external data sources 170, content platforms 180, and userdevices 190. The platform 100, the node computing devices 160, theexternal data sources 170, the content platforms 180, and the userdevices 190 may communicate via a communication network 10 (e.g., theInternet and/or a cellular network).

In embodiments, the tokenization platform 100 manages one or morecryptographic ledgers (or “distributed ledgers”) and provides flexiblefunctionality of virtual representations of items such as goods,services, and/or experiences with the fulfillment and satisfaction ofsaid items. In embodiments, the platform 100 provides a marketplace forthe 3rd party sellers to transact for items using tokens, whereby atoken is a digital marker that defines an ownership right in aparticular item. Additionally, or alternatively, the provider of theplatform 100 may sell, lease, give away, or otherwise transact itemsoffered by the provider. As used herein, the term “transaction” mayrefer to the sale/purchase, the leasing, the gifting, collateralization,or any other action that affects an ownership of a token. As will bediscussed, in some embodiments a token may be redeemed by an owner ofthe token, such that the owner of the token may take possession of theitem upon redemption of the token.

In some embodiments, the seller of an item (or any other suitable user)may access the platform 100 to define a virtual representation of theitem that the seller is offering for transaction. The virtualrepresentation of the item may include information that identifies theitem (e.g., a serial number corresponding to the item, a model number ofthe item, and the like), information relating to the item (e.g., aclassification of the item, textual descriptions, images, audio, video,virtual reality data, augmented reality data, and the like), and/or codethat may be used to facilitate or verify transactions involving the item(e.g., smart contracts). In some embodiments, the platform may“tokenize” an item on behalf of a seller of the item by generating a setof tokens based on the virtual representation of the item and storingthe tokens and associated metadata in a cryptographically securedistributed ledger, thereby making the tokens (and the virtualrepresentation) verifiable, transferable, and trackable.

In embodiments, the platform 100 may receive data from one or moreexternal data sources 170. An external data source 170 may refer to anysystem or device that can provide data to the platform. In embodiments,data sources may include merchant, manufacturer, or service providersystems and/or databases that provide the platform 100 with data relatedto an available item. External data sources may also include userdevices 190, such that the user devices 190 may provide relevant data(e.g., contacts, cookies, and the like). Examples of external datasources 170 may include e-Commerce websites, organizational websites,software applications, and contact lists (e.g., phone contacts, emailcontacts, messenger client contacts, and the like). The platform 100 mayaccess an external data source 170 via a network 10 (e.g., the Internet)in any suitable manner (e.g., crawlers, user permission/API, and thelike).

In embodiments, the platform 100 interacts with content publishingplatforms 180. A content publishing platform 190 may refer to any systemthat publishes content on behalf of individuals and/or organizations.Content publishing platforms may include social networking platforms,blogging platforms, news sites, and the like. In embodiments, a consumermay output content corresponding to an item via a content publishingplatform 190. For example, the consumer may post content related to apurchased item to a social networking platform or may embed the contentinto a blog post. The content may include links to the item (e.g., alink to a webpage or application state corresponding to the item).

In embodiments, the platform 100 interfaces with various user devices190. User devices 190 can refer to any computing device with which auser (e.g., consumer, merchant, manufacturer, provider and the like) canaccess the platform. Examples of user devices include, but are notlimited to, smartphones, tablet computer devices, laptop computingdevices, personal computing devices, smart televisions, gaming consoles,and the like. A user device may access the platform 100 via a website, aweb application, a native application, or the like. In embodiments, theplatform 100 may provide a first graphical user interface to userdevices 190 associated with a seller and a second graphical userinterface to a user device 190 associated with an end user. The firstgraphical user interface may allow a user associated with a seller tooffer items for sale and to create new virtual representationscorresponding to the items for sale. The second user interface may allowusers to purchase tokens corresponding to items for sale, to transfertokens, and/or redeem tokens. In some embodiments, the platform 100 maysupport a digital wallet that stores the tokens of a user. The digitalwallet may be a client application that is provided and/or supported bythe platform 100. In embodiments, the digital wallet stores any tokensthat are owned by the user associated with the digital wallet andprovides an interface that allows the user to redeem, transfer, sell,exchange, or otherwise participate in transactions involving the token.

In embodiments, the tokenization of items provides a framework forsecurely transacting with respect to an item represented by the token.For example, a token provides a mechanism by which an item may betraded, rented, purchased, sold, exchanged, gifted, swapped, ortransferred in transactions involving trusted or untrusted parties. Insome embodiments, a token represents a single unit to be transacted(e.g., sold, traded, leased, gifted, or the like). For example, if amerchant is selling ten widgets, the platform 100 may generate tentokens, where each token corresponds to a different widget. In thisscenario, all ten widgets may correspond to the same virtualrepresentation of the widget, and the ten tokens may represent instancesof the virtual representation (also referred to as a “virtual asset”).In embodiments, a token may be a digitally signed instance of thevirtual representation of an item, whereby the digital signature may beused to verify the validity of the token.

In embodiments, each virtual representation of an item may include or beassociated with a smart contract that, for example, provides a set ofverifiable conditions that must be satisfied in order to self-execute atransaction (e.g., transfer of ownership or expiration) relating to anitem represented by the virtual representation. In embodiments, eachtoken corresponding to a virtual representation may be associated withthe smart contract that corresponds to the virtual representation. Inembodiments, a smart contract corresponding to a virtual representationmay define the conditions that must be verified to generate new tokens,conditions that must be verified in order to transfer ownership oftokens, conditions that must be verified to redeem a token, and/orconditions that must be met to destroy a token. A smart contract mayalso contain code that defines actions to be taken when certainconditions are met. When implicated, the smart contract may determinewhether the conditions defined therein are satisfied, and if so, toself-execute the actions corresponding to the conditions. Inembodiments, each smart contract may be stored on and accessed on thedistributed ledger. In some embodiments, tokens that do not have a smartcontract associated therewith may be referred to as placeholder tokens,such that a placeholder token may not be involved in a transaction. Inembodiments, tokens can be gifted. In embodiments, recipients of agifted token may redeem the token, customize the virtual assetrepresented by the token before redemption, exchange it for anothertoken, obtain the cash value equivalent, and the like.

Once the platform 100 generates a token, the platform may update thedistributed ledger to indicate the existence of a new token. As usedherein, a distributed ledger may refer to an electronic ledger thatrecords transactions. A distributed ledger may be public or private. Inembodiments where the distributed ledger is private, the platform 100may maintain and store the entire distributed ledger on computing devicenodes 160 associated with the platform. In embodiments where thedistributed ledger is public, one or more 3rd party computing nodedevices 160 (or “computing nodes”) that are not associated with theplatform 100 may collectively store the distributed leger. In some ofthese embodiments, the platform 100 may also locally store thedistributed leger and/or a portion thereof. In embodiments, thedistributed ledger is a blockchain (e.g., an Ethereum blockchain).Alternatively, the distributed ledger may comport to other suitableprotocols (e.g., hashgraph, Byteball, Nano-Block Lattice, and IOTA). Bystoring tokens on a distributed ledger, the status of that token can beverified at any time by querying the ledger and trust that it iscorrect. By using the token approach to implementation, tokens cannot becopied and redeemed without permission.

In some embodiments, the platform 100 is configured to shard thedistributed ledger, such that there are side chains that fork from amain chain of a distributed ledger. In some of these embodiments, a sidechain may store virtual representations of items having a particularcategory or class. In embodiments, a side chain corresponding to aparticular class of items may store tokens corresponding to itemsbelonging to the particular class and ownership records that indicatethe current and previous ownerships of those tokens. Each time ownershipof a token changes, the side chain containing the implicated token maybe amended to indicate the new owner of the token. In embodiments, sidechains may store media contents that are associated with virtualrepresentations. For example, a side chain may store videos,photographs, audio clips, and other suitable media contents that arereferenced by respective virtual representations.

In addition to item data (e.g., virtual representations), tokens, andtransaction data relating to the tokens, the distributed ledger mayfurther store account information. For example, in embodiments thedistributed ledger may store the public addresses of each valid account.In embodiments, a valid account may belong to an entity that is verifiedand authorized by the platform to participate in a transaction. Thus, inembodiments, a party may only sell, purchase, gift, receive, orotherwise transfer a token if the party has a known account. Eachaccount may be assigned a public key and a private key that may be usedto transact on the platform 100. In embodiments, the address of anaccount may be based on the public key of the account (e.g., the addressmay be a hash value of the public key). These addresses may be stored inthe distributed ledger, such that addresses involved in a transactionmay be verified as corresponding to valid accounts using the distributedledger.

In operation, a seller may instruct the platform 100 to generate virtualrepresentations of one or more respective items, such that each virtualrepresentation represents a respective item that is available for atransaction. It is noted that while many of the examples of transactionsin the disclosure relate to purchases of goods, services, and/orexperiences, transactions may also include leases, rentals, loans,gifts, trades, rewards, or giveaways. In embodiments, the seller mayprovide item attributes relating to a set of one or more items, such asa number of items available for transaction, pricing information of anitem, delivery restrictions for the item, expiries relating to the item(e.g., how long is the transaction valid), an item description, a serialnumber (e.g., of physical items), media relating to the item (e.g.,photographs, videos, and/or audio content), and the like. In response tothe seller providing the item information, the platform 100 generates aset of tokens corresponding to the number of items available fortransaction. For example, if the seller indicates that there are 100Model X widgets available for sale, the platform 100 may generate avirtual representation of the Model X widget and may generate 100non-fungible tokens corresponding to the virtual representation, wherebyeach token corresponds to a respective instance of the virtualrepresentation. The virtual representation may include a description ofthe widgets, a description of the widgets, a price of the widget,shipping restrictions relating to the widgets, photographs of thewidgets, videos of the widget, virtual reality data relating to thewidget, and the like. The platform 100 may then store the virtualrepresentation and the corresponding tokens on the distributed ledger.For each token, the distributed ledger may store the token, ownershipdata relating to the token, media content corresponding to the token (orthe virtual representation to which the token corresponds), and/or othersuitable data relating to the token on the distributed ledger.Initially, the ownership of the token may be assigned to the seller. Assuch, the distributed ledger may indicate the existence of the token andthat the seller owns the token. Once tokenized, end users (e.g., buyers)may participate in transactions for the item using the correspondingtoken. For example, the user may purchase a token corresponding to theitem from the seller via a web interface or application that is providedor supported by the provider of the platform 100. In response to thetransaction, the platform 100 may update the distributed ledger toindicate an assignment of the token to the user (e.g., to a walletassociated with an account of the user). In embodiments, a copy of thetoken may be stored in a digital wallet corresponding to the new ownerof the token (e.g., the buyer).

A token may be transmitted amongst users in any suitable manner. Forexample, a token may be transmitted via email, instant message, textmessage, digital transfer, social media platforms, and the like. In someof these embodiments, the token may be transmitted directly from thesender's user device 190 (e.g., from the user's digital wallet) to auser device 190 (e.g., smartphone) or account (e.g., email account ormessaging application) associated with the intended recipient. Uponinitiating the transmission, the digital wallet may transmit a transferrequest to the platform 100 and may transmit a copy of the token to therecipient's user device 190 or specified account. In some embodiments,the transmitted token may be embedded in a media content, such as animage, emoji, or video, such that the recipient receives the mediacontent and may opt to accept the token. In this example, the token maybe accompanied by a link and/or software instructions that cause theuser device 190 that receives the token to add the token to therecipient's account upon the recipient accepting the token. Uponelecting to accept the token, the user device 190 of the recipient maytransmit a request to the platform to add the token to an account of therecipient. The platform 100 may receive the request and may update theownership record of the token in the distributed ledger to indicate thetransfer of ownership.

In embodiments, an owner of a token may redeem a token. In embodiments,a user may select a token to redeem from a digital wallet of the user.In response to the selection, the digital wallet may transmit a redeemrequest to the platform 100. The redeem request may include the token(or an identifier thereof) and a public address of the user (or anyother suitable identifier of the user). The platform 100 receives theredeem request and verifies the validity of the token and/or theownership of the token. Once verified, the user is granted permission toredeem the token. In some scenarios, the user may be redeeming a tokencorresponding to a digital item (e.g., a gift card, an mp3, a movie, adigital photograph). In these scenarios, the platform 100 may determinea workflow for satisfying the digital item. For example, the platform100 may request an email address from the user or may look up an emailaddress of the user from the distributed ledger. In this example, theplatform 100 may email a link to download the digital item to the user'semail account or may attach a copy of the digital item in an email thatis sent to the user's email account. In another scenario, the user maybe redeeming a token corresponding to a physical good (e.g., clothing,food, electronics, etc.) or a physical service (e.g., maid service). Inthe case of a physical good, the platform 100 may determine a workflowfor satisfying the physical item. For example, the platform 100 mayrequest shipping information from the user or may look up the shippinginformation of the user from the distributed ledger. The platform 100may then initiate shipment of the physical good. For example, theplatform 100 may transmit a shipping request to a warehouse that handlesshipments of the good indicating the shipping information. The foregoingare examples of how a token may be redeemed. The platform 100 mayexecute additional or alternative workflows to handle redemption of atoken.

In embodiments, the token may be printed in physical media, such thatthe token may be redeemed at a brick and mortar location. For example,the token (e.g., an alphanumerical string) may be encoded into a QR-codeor barcode. In these embodiments, the public key of the party that wasused to digitally sign the token (e.g., a public key associated with theplatform 100) may also be provided in the physical media. In this way,the token may be verified by scanning the QR-code or barcode using aclient application associated with the platform 100. The clientapplication may provide the token and the public key to the platform100, which may verify the validity of the token based on the token andthe public key. If the token and ownership are verified, the platform100 may transmit a confirmation of the verification to the clientapplication. A clerk may then allow the user to complete the transaction(e.g., take possession of the item).

In some embodiments, tokens may be perishable, in that they lose allvalue at a predetermined time or upon the occurrence of a predeterminedevent. In these embodiments, the seller may provide an expiry in thevirtual representation that indicates a date and time that the virtualrepresentation is no longer valid, such that when the expiry is reached,the token may be deemed invalid.

Tokens may be fungible tokens or non-fungible tokens. Fungible tokensmay refer to tokens that are interchangeable. For example, fungibletokens may all have the same identifier. Non-fungible tokens are uniquetokens. Non-fungible tokens are transferrable but not interchangeable.

In embodiments, the platform 100 may execute one or more of: amarketplace system 102, a ledger management system 104, a transactionsystem 106, an API system 108, an intelligence and automation system110, an analytics and reporting system 112, and/or virtual worldpresence system 114, all of which are discussed in greater detailthroughout this disclosure.

In embodiments, the platform 100 provides a marketplace system 102 thatallows virtual representations of items to be defined, generated,viewed, and/or redeemed. In embodiments, the marketplace system 102 mayinclude graphical user interfaces that: allow sellers to define virtualrepresentations, allow consumers to view virtual representations ofitems and to transact for tokens corresponding to the items, and allowtoken owners to redeem tokens, thereby completing transactions for itemsindicated by the redeemed tokens. The marketplace system 102 may furtherinclude backend functionality for supporting these operations.

In embodiments, the platform 100 provides a ledger management system 104that generates tokens and manages one or more distributed ledgers,including managing the ownership rights of the generated tokens. Inembodiments, the ledger management system 104 may also interface withone or more smart contracts that implicate the distributed ledgers.

In embodiments, the platform 100 includes an API system 106 that managesone or more application programming interfaces (APIs) of the platform,so as to expose the APIs to one or more related applications (e.g.,native and/or web applications provided by the platform 100 provider),third party systems that are supported by or otherwise interact with theplatform 100, and smart contracts that are configured to interface withthe platform 100. The API system 106 may expose one or more APIs, suchthat the API system 106 may receive API calls from requesting devices orsystems and/or may push data to subscribing devices or systems. The APIsystem 106 may implement any suitable types of APIs, including REST,SOAP, and the like. In embodiments, the API system 106 may include asmart contract API that allows smart contracts to interface with theplatform, a utility API, a merchant API that allows merchants to createtokens corresponding to virtual representations of items, and any othersuitable APIs. In embodiments, the platform 100 may implement a microservices architecture such that services may be accessed by clients,such as by APIs and/or software development kits (SDKs). The servicesabstract away the complexities of blockchain creation, object handling,ownership transfers, data integration, identity management, and thelike, so that platform users can easily build, deliver and/or consumeplatform capabilities. In embodiments, SDK types include, but are notlimited to: an Android SDK, an iOS SDK, a Windows SDK, a JavaScript SDK,a PHP SDK, a Python SDK, a Swift SDK, a Ruby SDK, and the like.

In embodiments, the platform 100 includes a transaction system 108 thatsupports any suitable transactions relating to the platform, includingthe buying, selling, trading, renting, leasing, exchanging, swapping,transferring, and/or redeeming of tokens that represent correspondingitems.

In embodiments, the platform 100 includes an intelligence and automationsystem 110 that performs machine learning and artificial intelligencetasks. For example, the intelligence and automation system 110 may trainmachine learned models, make classifications and predictions based onthe machine learned models, recommend products to users, identifyadvertisements to target to specific users, match service providers toservice seekers, and/or automate notifications to users.

In embodiments, the analytics and reporting system 112 performsanalytics-related tasks relating to various aspects of the tokenizationplatform 100 and may report the resultant analytics to interestedparties (e.g., employees of the platform provider 100 and/or sellers onthe platform 100).

In embodiments, the platform includes or supports a virtual worldpresence system 114 that provides presents virtual representations ofitems in virtual world environments. For example, the virtual worldpresence system 114 may present a virtual reality store to a user,whereby virtual representations of items are presented in the store andusers can “shop” for the virtual items in the virtual world environment.In these embodiments, the virtual world presence system 114 may render avirtual world environment, which may be displayed at a clientapplication. The virtual world environment may be associated with aseller or a group of sellers, whereby items that are sold by the selleror sellers are made available in the virtual world environment. In theseembodiments, the virtual world presence system 114 may further render 3Drepresentations of items that are available from the seller or sellersbased on the virtual representations of the items. The 3Drepresentations may then be presented in the virtual world environments,such that users can examine the 3D representations of the items (e.g.,look at the representations from different angles). In the event a userwishes to purchase an item, the user may initiate a transaction (e.g.,selecting a “buy” button in the virtual representation). Upon the userinitiating the transaction, the virtual world presence system 114 maynotify the transaction system 106 of the user's selection, and thetransaction may precede in the manner described above.

In embodiments, the platform 100 includes a user management system 116.In embodiments, the user management system 116 may create new useraccounts, assess risk associated with users, provide conditions forusers based on respective risk associated with the users whenparticipating in a transaction, and the like.

In some embodiments, the user management system 116 creates new accountsfor users. In these embodiments, a new user may access the platform 100and may request a new account. In embodiments, the platform 100 mayallow a user to link their account to an account of an external system(e.g., Google®, Facebook®, Twitter®, etc.). Additionally, oralternatively, a user can provide an email address and login. Inembodiments, the user management system 116 may request a user toprovide additional authenticating information, such as a home address orbusiness address, a passport number (and/or image of the passport),driver's license number (and/or an image thereof), state ID card (and/oran image thereof). The user management system 116 may further provide amechanism for a user to link any financial information to the platform,including entering credit card numbers, banking information,cryptocurrency wallets (e.g., Coinbase® account), and the like. Uponreceiving the requested information, the user management system 116creates a new account for the user, including creating a new publicaddress of the account corresponding to the user. Once the account iscreated, the user may begin participating in transactions on theplatform 100.

In embodiments, the user management system 116 determines a risk scoreof a user each time the user attempts to participate in a transactionusing the platform 100. A risk score of a user may indicate a degree ofrisk associated with facilitating a particular transaction involving theuser. Examples of risks may include a risk that a seller will notdeliver an item purchased by another user, a risk that the seller willdeliver a fake or substandard item to another user, a risk that a userwill default on a loan, a risk that the user will engage in fraud, andthe like. Factors that may be relevant to a user's risk score mayinclude, but are not limited to, whether the user has provided secondaryauthentication information (e.g., passport or driver's license), whetherthe user has provided banking information, how many purchases or salesthe user has made on the platform 100, the size of those transactions,how many issues the user has had with previous transactions (e.g., howmany non-payments or non-deliveries, complaints, etc.), whether the userhas defaulted on a loan facilitated by the platform, and the like.

In some embodiments, the user management system 116 may determine therisk score using a risk scoring model trained to assess risks associatedwith the user given a transaction. Upon a user attempting to engage in atransaction, the user management system 116 may determine the featuresof the transaction (e.g., type of transaction, the size of thetransaction, etc.) and the features of the user (the outcomes of theuser's previous transactions, the types of those transactions, whetherthe user has provided secondary authentication information, whether theuser has provided banking information, whether the user has had issuesin the past, etc.). For example, when a user requests to sell an item,requests a collateralized loan, or the like, the user management system116 may determine a risk score. The user management system 116 mayprovide the features to the intelligence and automation system 110,which may input the features into the risk scoring model. The riskscoring model may output a risk score based on the features, where therisk score indicates a probability that the transaction will besuccessful given the transaction features and user features. Inembodiments, the risk scoring model may be trained by the intelligenceand automation system 110 (e.g., the machine learning system 502 of FIG.5), as is discussed below.

In embodiments, the user management system 116 may impose a set ofconditions on a user requesting to participate in a transaction based onthe risk associated with the user. Examples of conditions may includerequiring a user to place funds in escrow equal to the sale price of anitem to be sold on the platform (e.g., an amount to be refunded if aseller does not provide an item or provides a fake item), requiring auser to provide collateral in excess of a loan amount if there issignificant risk that the user defaults on a loan, requiring a user toprovide secondary authentication information if the user is requesting aloan and has not provided such information, and the like, For example,if the user is requesting to sell an item on the platform 100, but theuser does not have a history of selling items, the risk score associatedwith the potential transaction may indicate that there is a risk thatthe seller will not successfully deliver an item or that the item may befake or in an unsatisfactory condition transaction. In this example, theplatform 100 may require that the user deposit (or have in his or heraccount) an amount of funds that are equal to or greater than sale priceof the item or items that the user wishes to sell. In this way, theplatform 100 may issue a refund to a buyer if the user (i.e., seller)does not successfully complete the transaction. In embodiments, the usermanagement system 116 may implement a set of rules to determine theconditions, if any, to place on a user with respect to a particulartransaction if the user wishes to engage in the transaction. Inembodiments, a rule may define one or more conditions that correspond toparticular types of transactions (e.g., selling, trading, borrowing,etc.) and may define risk score thresholds that trigger the one or moreconditions.

The platform 100 may execute additional or alternative systems as well.For example, in embodiments, the platform 100 may include a gamificationsystem (not shown) that gamifies aspects of the platform 100 and/or arewards system (not shown) that rewards users for participating incertain activities. For example, the gamification system may provide anenvironment where users are challenged to compete for the most sharedvirtual items on social media platforms. In this example, the rewardssystem may reward users with tokens to redeem items when the users aredeemed to have shared the most virtual items on the social mediaplatforms. In another example, the rewards system may issue rewards(e.g., tokens to certain items) to a user when the user purchases acertain value or amount of virtual items.

In embodiments, the platform 100 can include a logistics system (notshown) that enables the physical delivery of an item, such as a good orfood. The logistics system may be configured to manage the logisticsfrom the source location of the item (e.g., a warehouse or restaurant)to the redeemer of the token (e.g., the house or current location of theredeemer). In embodiments, the logistics system may include ageolocation system (not shown) for determining delivery location. Forexample, if an owner of a token corresponding to a pizza with onetopping from a pizza delivery chain redeems the token, the geolocationsystem may determine the recipient's current location for delivery.Geolocation information may be acquired by a smart phone, web browser(e.g., IP address), or the like. In this example, the logistics systemmay generate an electronic notification based on the user's geolocation(or a selected delivery location) and the user's order (e.g., the user'sselected topping) and may transmit the electronic notification to alocation of the pizza delivery chain that is closest to the intendeddelivery location.

FIG. 2 illustrates an example of a marketplace system 102 according tosome embodiments of the present disclosure. In embodiments, marketplacesystem 102 may include an item management system 202, a buyermarketplace system 204, and a redemption system 206.

The item management system 202 allows a seller of an item to define avirtual representation of an item. In embodiments, the item managementsystem 202 presents a GUI to a user device 190 of the seller that allowsthe seller to define the attributes of the item. In the case that theitem has never been sold on the platform 100, the seller can select anoption to add a new item. In response to doing so, the seller mayprovide an item classification that indicates the type of item (e.g.,“shoes,” “pizza,” “photograph,” “movie,” “concert tickets,” “gift card,”and the like) and a name of the item. The seller may then define one ormore additional attributes of the item. For example, in embodiments, theseller may provide an item description, media contents associated withthe item (e.g., photographs, videos, audio clips, and the like),relevant links (e.g., a link to a website of the seller), a price of theitem, restrictions relating to the item (e.g., “US shipping only” or“seller store hours are 10-6”), redemption instructions (e.g., whetherin store redemption is allowed, permitted, or mandatory, whether digitalassets are downloaded or emailed, whether the items are transferrable,and the like), a number of the item that are available for transaction(e.g., how many units are available), and/or any other suitableattributes. In response to the seller providing the item attributes, theitem management system 202 may generate a virtual representation of theitem. In embodiments, the virtual representation may be a data recordthat includes the attributes of the item. In the scenario where thevirtual representation was previously defined, the seller may select thepreviously defined item and may update one or more attributes. Forexample, the seller may provide additional media contents, may alter theprice, and/or may update the number of items that are available. Whetheran updated virtual representation or a newly defined virtualrepresentation, the item management system 202 may output the virtualrepresentation to the ledger management system 104, where the ledgermanagement system 104 may tokenize instances of the virtualrepresentation to obtain a set of tokens.

In some embodiments, the item management system 202 may allow the sellerto provide seller attributes as well. The seller may provide informationsuch as a physical location where physical items may be shipped from, adigital location where digital items may be retrieved from, physicallocations of the seller's brick and mortar stores, hours of operation ofthe seller, and the like. These attributes may be included in thevirtual representation or may be stored in an alternate date record.

In embodiments, the item management system 202 may include an asset typemanager for creating and defining new types of items to enable theplatform 100 to support the sale and trade of the new type of asset. Inthese embodiments, the asset type manager may provide a GUI that allowsa user to define a new type of asset. In these embodiments, an assettype attributes field allows users to add information specific to newasset types as they are being defined. Attribute information can beunderstood as information material to purchasers in making a buyingdecision and must be information specific to an asset type andinformation capable of being displayed on the platform. Asset typeattribute fields include, but are not limited to, an asset type name, anasset type image, an asset redemption URL, an asset descriptor (e.g.,physical or digital), and the like.

In embodiments, the item management system 202 may include an item typedefinition manager for defining new types of items so that they can belisted on the platform. In embodiments, the item type definition managermay provide a GUI that allows a user to define attributes of a new item.To define a new item type, a user may be prompted to select anappropriate asset type from the dropdown menu. The GUI may then allow auser to define the item attributes in item attribute fields. Itemattribute fields may include, but are not limited to, an item name, anitem description, item notes, an item image, item pricing data (e.g.,suggested price, suggested floor price), an instant sell flag, an itemURL that links to a webpage for purchasing the item, a quantity ofitems, and the like. When a user provides the requisite item attributes,the item management system 202 may create a new virtual representationdefining the new item.

In some embodiments, the item management system 202 may require sellerswithout adequate history to escrow an amount of funds equal to the valueof the goods being sold on the tokenization platform 100. The seller maysell a token representing an item, and when the token is redeemed by thetoken owner (e.g., the buyer or downstream recipient), the funds areremoved from escrow and returned to an account of the seller. In theseembodiments, the seller does not need to escrow the physical item, whichrequires at least one additional shipment to be made to a warehouse orother storage facility.

In embodiments, the buyer marketplace system 204 allows a consumer tobrowse or search for items, view virtual representations of items, andengage in transactions for the items. In embodiments, the buyermarketplace system 204 presents a GUI that includes a search bar thatallows users to enter a search query comprised of one or more searchterms. In response to receiving the search query, the buyer marketplacesystem 204 may query one or more indexes that index virtualrepresentations using one or more of the search terms. The buyermarketplace system 204 may process the search query and perform thesubsequent search using any suitable search techniques. In response toperforming the search, the buyer marketplace system 204 may retrieve thevirtual representations implicated by the search and may present thevirtual representations in a visual manner. For example, the GUI maydisplay a search engine results page (SERP) that displays one or moresearch results, where each search result corresponds to a differentvirtual representation and links to a respective page where the user canview the attributes of the item as defined in the virtual representationof the item, including any media contents associated with the item andthe price of the item, and can elect to purchase a token correspondingto the item.

In embodiments, the buyer marketplace system 204 may allow users tobrowse virtual items offered on the platform. For example, the buyermarketplace system 204 may present a GUI that allows a consumer tofilter items by category or by other attributes. The GUI may allow auser to select a link corresponding to an item, which directs the userto a page where the user can view the attributes of the item as definedin the virtual representation of the item, including any media contentsassociated with the item and the price of the item, and can elect topurchase a token corresponding to the item.

In embodiments, when the consumer elects to purchase an item, the buyermarketplace system 204 may notify the ledger management system 104regarding the purchase. The buyer marketplace system 204 may provide theledger management system 104 with the public address of the user and anidentifier of the virtual representation of the selected item. Theledger management system 104 may effectuate the transaction by assigninga token from the set of tokens corresponding to the virtualrepresentation to the account associated with the public address of theuser and updating the distributed ledger to indicate the change ofownership of the assigned token to the public address of the user. Forexample, the buyer marketplace system 204 (or the transaction system106) may identify a token that is currently owned by the seller and maytransfer ownership of the token to an account of the buyer. Once thisoccurs, a copy of the token may be deposited into an account of theuser. For example, the token may be deposited in a digital wallet of theuser.

In embodiments, the buyer marketplace system 205 may depict items asindividual thumbnail images. In some of these embodiments, a simple boxstyle user interface element can be added to the Item detail pages todisplay the attributes of an item, including an item descriptionattribute, item notes attributes, and a seller URL attribute. An itemdescription field on the GUI can support clickable URLs that canredirect platform users to pages with more information about the productor other relevant pages. The item description textbox can be displayedand support links to third-party domains.

In embodiments, the buyer marketplace system 204 may allow users topurchase made-to-order items. For example, a user may order a customizedpizza, piece of furniture, flower arrangement, or the like. Users candigitally build items consisting of multiple items from multiplemerchants and have the item 3D printed at a 3D printing station.

FIG. 3 illustrates an example of a ledger management system 104 of thetokenization platform 100 that manages one or more distributed ledgers210 in accordance with some implementations of the present disclosure.In embodiments, the ledger management system 104 includes a tokengeneration system 302, a ledger update system 304, and a verificationsystem 306. The token generation system 302 may be configured togenerate tokens that correspond to items made available for transactionand that are based on respective virtual representations of the items.The ledger update system 304 receives requests to update the distributedledger 310 and updates the distributed ledger accordingly 310. Theverification system 306 receives requests to verify a token, an account,or the like and attempts to verify the token or account based on thedistributed ledger.

In embodiments, the distributed ledger 310 may be a public ledger, suchthat N node computing devices 160 store N respective copies of theledger 310, where each copy includes at least a portion of thedistributed ledger 310. In other embodiments, the distributed ledger 310is a private ledger, where the ledger is distributed amongst nodes undercontrol of the platform 100. In embodiments, the distributed ledger 310is a blockchain (e.g., an Ethereum blockchain comporting to the ETCprotocol). Alternatively, the distributed ledger 310 may comport toother suitable protocols (e.g., Hashgraph, Byteball, Nano-Block Lattice,or IOTA). By storing tokens on a distributed ledger 310, the status ofthat token can be verified at any time by querying the ledger and trustthat it is correct. By using the token approach to implementation,tokens cannot be copied and redeemed without permission.

The distributed ledger 310 may store any suitable data relating to anitem, a user, a seller, and the like. In embodiments, the distributedledger 310 may store item-related data. Item-related data may include,but is not limited to, item identifiers, expiration dates of items,conditions or restrictions placed on the items, item descriptions, mediacontent related to items (e.g., photographs, logos, videos, and thelike), documentation of the item, customization options, availablesizes, available colors, available materials, functionality options,ingredients, prices, special offers or discounts relating to the item,location information (e.g., where an item can be delivered/provided),hours available, owner/custodian data, reviews, item type, and the like.In embodiments, the distributed ledger 310 may store user data. Userdata may include, but is not limited to, identifying information (e.g.,user ID, email address, name, and the like), public address, financialinformation (e.g., credit card information), transaction history,location data (e.g., a region of the user or country of the user),preferences, a wish list, subscriptions of the user, items belonging tothe user, user connections or contacts, media content relating to theuser (e.g., photos or videos of the user), an avatar of the user, andthe like. In embodiments, the distributed ledger 310 may storemerchant-related data. Merchant-related data may include, but is notlimited to, identifying information (e.g., a name of the merchant, amerchant ID, and/or the like), contact information of the merchant,experience data, location data, hours available, reviews, media content(photographs, videos, and the like), and/or any other suitablemerchant-related data. A distributed ledger 310 may store additionaland/or alternative data.

In embodiments, the distributed ledger 310 includes side chains 314. Aside chain 314 may refer to a shard of the distributed ledger 310 thatextends from a segment (e.g., a block) of a main chain 312 of the ledger310. In embodiments, the main chain 312 may store data that is relatedto merchants and users with accounts (e.g., public addresses).Additionally, or alternatively, the main chain 312 may store itemclassification data, such as descriptions of item classifications. Inembodiments, a side chain 314 may pertain to a particular classificationof item. In some of these embodiments, side chains 314 may store virtualrepresentations of items belonging to a respective genus or class ofitems and data relating to those items. For example, a first side chain314-1 may store virtual representations of shoes that are available onthe platform 100 and any token-related data relating to those virtualrepresentations. In embodiments, side chains 314 may store mediacontents that are used in connection with items available fortransaction on the platform. For example, a second side chain 314-2 maystore photographs depicting shoes represented in the first side chain314-1, video clips depicting shoes represented in the first side chain314-1, audio clips relating to shoes represented in the first side chain314-1, virtual reality content depicting shoes represented in the firstside chain 314-1, augmented reality content depicting shoes representedin the first side chain 314-1, and the like. The foregoing is one mannerto shard a distributed ledger. The distributed ledger 310 may be shardedin any other suitable manner.

In embodiments, the token generation system 302 receives a virtualrepresentation and generates one or more tokens corresponding to thevirtual representation. In embodiments, the virtual representationincludes attributes of an item, including a number (if bounded) ofavailable items (i.e., the number of items available for transaction).In embodiments, the number of available items indicates the number oftokens that the token generation system 302 generates for a particularvirtual representation. The attributes may also include otherrestrictions relating to the item, such as an expiry of a token (e.g.,how long a token may be valid). The token generation system 302 may alsoreceive initial ownership data. The initial ownership data defines theinitial owner of a token. As a default, the entity offering the itemrepresented by the virtual representation (e.g., the merchant of theitem) is the initial owner of the token. The initial ownership may,however, be assigned to a different entity.

In embodiments, the token is a wrapper that wraps an instance of avirtual representation. In some of these embodiments, the tokengeneration system 302 may generate a token identifier that identifiesthe token. In scenarios where the tokens are non-fungible tokens, thetoken generation system 302 may generate a unique identifier for eachrespective token corresponding to the virtual representation. The tokengeneration system 302 may generate the token identifier using anysuitable technique. For example, the token generation system 302 mayimplement random number genesis, case genesis, simple genesis, and/ortoken bridge genesis to generate a value that identifies the token. Inembodiments, the token generation system 302 may digitally sign thevalue using a private key/public key pair. The token generation system302 may utilize a private key/public key pair associated with theplatform 100 or the merchant to digitally sign the value that identifiesthe token. The token generation system 302 may implement any suitabledigital signature algorithm to digitally sign the value that identifiesthe token, such as the Digital Signature Algorithm (DSA), developed bythe National Institute of Standards and Technology. In embodiments, theresultant digital signature may be used as the token identifier. Foreach token, the token generation system 302 may generate a token wrapperthat includes the token identifier and the virtual representation of theitem. In embodiments, the token generation system 302 may embed orotherwise encode the public key used to digitally sign the token in thetoken. Alternatively, the token generation system 302 may store thepublic key apart from the token, such that the public key iscommunicated to an account of the token owner each time the token istransferred to a new owner. Upon generating a non-fungible token, thetoken generation system 302 may output the non-fungible token to theledger update system 304. The wrapper may wrap a plurality of tokens,including fungible tokens and non-fungible tokens.

In some embodiments, the token generation system 302 may generatefungible tokens. In these embodiments, the token generation system 302may generate identical tokens, where each token has the same tokenidentifier. In these embodiments, the token generation system 302 maygenerate a single token identifier, in the manner described above, andmay generate N fungible tokens using that token identifier, where N isthe number of total tokens. Upon generating the N fungible tokens, thetoken generation system 302 may output the N fungible tokens to theledger update system 304.

In embodiments, the ledger update system 304 is configured to update andmaintain one or more distributed ledgers 310. As used herein, updatingand maintaining a distributed ledger 310 may refer to the writing ofdata to the distributed ledger 310. In embodiments, the ledger updatesystem 304 may generate a block in accordance with the protocol to whichthe distributed ledger comports, where the block contains the data to bewritten to the distributed ledger 310. In embodiments, the ledger updatesystem 304 may update the distributed ledger 310 by broadcasting thegenerated block to the computing nodes 160 that store the distributedledger 310. The manner by which a computing node 160 determines whetherto amend the received block to its local copy of the distributed ledger310 may be defined by the protocol to which the distributed ledgercomports.

In embodiments, the ledger update system 304 receives tokens and updatesthe distributed ledgers 310 based thereon. In some of these embodiments,the ledger update system 304 receives a token and ownership data (e.g.,a public address of the entity to which the token is to be assigned) andupdates the distributed ledger 310 based thereon. For example, theledger update system 304 may generate a block having the token embeddedtherein. The generated block or a subsequently generated block mayinclude the ownership data pertaining to the token. The ledger updatesystem 304 may then write generated block(s) to the distributed ledger310. For example, the ledger update system 304 may amend the block(s) toa copy of the distributed ledger 310 maintained at the platform 100and/or may broadcast the block(s) to the computing nodes 160 that storecopies of the distributed ledger 310, which in turn amend the respectivecopies of the distributed ledger with the broadcast block(s). Inembodiments where the distributed ledger 310 is sharded, the ledgerupdate system 304 may designate a side chain 314 (e.g., an itemclassification) to which the token corresponds. In these embodiments,the generated blocks are amended to the designated side chain 314 toindicate the existence of the token and the current ownership of thetoken.

In embodiments, the ledger update system 304 receives an ownershipchange request requesting to change ownership of a token to anotheraccount. For example, the ledger update system 304 may receive anownership change request in response to a purchase of a token, a giftingof a token, a resale of the token, a trade of a token, and the like. Insome embodiments, the ownership change request may define a token to betransferred and a public address of the transferee of the token (e.g., arecipient of the token). In some embodiments, the ownership changerequest may further include a public address of the current owner of thetoken (assuming the token has a current owner). The ledger update system304 may receive the ownership change request and may generate a block toindicate the new owner of the implicated token. The ledger update system304 may then write generated block(s) to the distributed ledger 310. Forexample, the ledger update system 304 may amend the block(s) to thedistributed ledger 310 and/or may broadcast the block(s) to thecomputing nodes 160 that store the distributed ledger 310. Inembodiments where the distributed ledger 310 is sharded, the ledgerupdate system 304 may designate a side chain 314 (e.g., an itemclassification) to which the token corresponds. In these embodiments,the generated blocks are amended to the designated side chain 314 toindicate the new owner of the token.

In embodiments, the ledger update system 304 receives a new or alteredvirtual representation and updates the distributed ledger 310 to reflectthe new or altered virtual representation. For example, the ledgerupdate system 304 may receive a new visual representation when a sellerdefines a new item that is available for transaction. The ledger updatesystem 304 may receive an altered virtual representation in response toa seller altering one or more attributes of a previously defined virtualrepresentation. In embodiments, the ledger update system 304 receives anew or altered virtual representation and generates one or more blocksbased on the received virtual representation. The ledger update system304 may then write the generated block(s) to the distributed ledger 310based on the generated block(s). For example, the ledger update system304 may amend the block(s) to the distributed ledger and/or maybroadcast the block(s) to the computing nodes 160 that store thedistributed ledger. In embodiments where the distributed ledger 310 issharded, media content pertaining to a virtual representation may bestored in a separate side chain 314. In some of these embodiments, themedia contents may be stored in separate blocks from the virtualrepresentation, where the block containing the virtual representationmay include references to the blocks containing the corresponding mediacontents. The ledger update system 304 may designate a side chain 314(e.g., an item classification) to which the virtual representationcorresponds and a side chain 314 to which the media content block(s)should be corresponds. In these embodiments, the generated blocks areamended to the respective designated side chains 314 to indicate the newor amended virtual representation. The ledger update system 304 may thenwrite generated block(s) to the distributed ledger 310. For example, theledger update system 304 may amend the block(s) to the distributedledger 310 and/or may broadcast the block(s) to the computing nodes 160that store the distributed ledger 310. In embodiments where thedistributed ledger 310 is sharded, the ledger update system 304 maydesignate a side chain 314 (e.g., an item classification) to which theburned token corresponds. In these embodiments, the generated blocks areamended to the designated side chain 314 to indicate the new and/oramended virtual representation(s).

In embodiments, the ledger update system 304 is further configured to“burn” tokens. Burning tokens may refer to the mechanism by which atoken is deemed no longer redeemable. A token may be burned when thetoken expires or when the token is redeemed. In embodiments, the ledgerupdate system 304 may update the ownership of the token to indicate thatthe token is not currently owned (e.g., owner=NULL) and/or may updatethe token state to indicate that the token is no longer valid. In someof these embodiments, the ledger update system 304 may generate a blockindicating that the token is not currently owned or that the state ofthe token is not valid. The ledger update system 304 may then writegenerated block(s) to the distributed ledger 310. For example, theledger update system 304 may amend the block(s) to the distributedledger 310 and/or may broadcast the block(s) to the computing nodes 160that store the distributed ledger 310. In some embodiments, thedistributed ledger 310 is sharded. In these embodiments, the ledgerupdate system 304 may designate a side chain 314 (e.g., an itemclassification) to which the token corresponds. In these embodiments,the generated blocks are amended to the designated side chain 314 toindicate the burned token.

The ledger update system 304 may update the distributed ledger 310 toindicate other data as well. In embodiments, the leger update system 304may maintain and update merchant data and/or user data on thedistributed ledger 310. For example, the ledger update system 304 maymaintain a public address list of valid accounts. The ledger updatesystem 304 may update the cryptographic ledger to reflect new accountsthat are added to the platform 310 with the public addresses of thoseaccounts. The ledger update system 304 may store additional oralternative merchant and user data on the distributed ledger as well.

In embodiments, the verification system 306 verifies data stored on thedistributed ledger 310. In embodiments, the verification system 306 mayverify the validity of tokens and/or may verify the ownership of atoken. The verification system 306 may be configured to validate othertypes of data stored on the distributed ledger 310 as well.

In embodiments, the verification system 306 receives a tokenverification request. The token verification request may include a tokento be verified or a token identifier thereof. In these embodiments, theverification system 306 may determine whether the token identifier ofthe token to be verified is stored on the distributed ledger 310. If itis not stored on the distributed ledger 310, the verification system 306may deem the token to be invalid. In some embodiments, the tokenverification request may further include a public key to be used toverify the token. In these embodiments, the verification module 306 mayuse the received public key to determine whether the public keycorresponds to a token that is stored in the distributed ledger 310. Insome of these embodiments, the verification system 306 use the receivedpublic key and the private key used to encode the digital signature todetermine whether the received public key is the public key used to signthe token. For example, in embodiments, the verification system 306 mayattempt to decrypt the digital signature using the private key and thereceived public key. If the private key and the received public keyenable decryption of the digital signature to obtain the value used togenerate the token, then the verification system 306 may deem the tokenvalid and may notify the requesting system of the verification.

In embodiments, the verification system 306 may be configured to verifythe ownership of a token. In these embodiments, the verification system306 may receive a public address to be verified and a token (or anidentifier thereof). In some embodiments, the verification system 306may verify that the public address corresponds to an account on theplatform 100. For example, the verification system 306 may determinewhether the public address is stored in the public address list on thedistributed ledger 310. If so, the verification system 306 may determinewhether the ownership data relating to the token is currently owned bythe account indicated by the received public address. If so, theverification system 306 may verify the ownership of the token and mayoutput the verification to the requesting system.

FIG. 4 illustrates an example of a transaction system 106 of thetokenization platform 100, according to some embodiments of the presentdisclosure. In some embodiments, the transaction system 106 include atoken transfer system 402 and a redemption system 404. The transactionsystem 106 may include additional or alternative systems withoutdeparting from the scope of the disclosure. For example, the transactionsystem 106 may include a digital wallet system 408, an express tradingsystem 410, a payment integration system 412, a subscription system 414,and/or a token bridging system 416.

In embodiments, the token transfer system 402 facilitates the transferof tokens from an account of an owner of the token an account of adifferent user. In embodiments, token transfer system 402 may includesmart contracts that define the conditions under which a token may betransferred. In some of these embodiments, smart contracts may reside intokens, such that the smart contract may execute at a node computingdevice and/or from a digital wallet. In some of these embodiments, asmart contract may interface with the token transfer system 402 via asmart contract API that is exposed by the API system 108.

In embodiments, the token transfer system 402 receives a transferrequest that requests a transfer of a token to an account. A transferrequest may be received from an account of the token holder or from theaccount of the intended recipient of the token. In embodiments, thetransfer request may include a public address of the account to whichthe token is to be transferred and may further include or indicate thetoken to be transferred. For example, the transfer request may include acopy of the token or a value (e.g., an alphanumeric string) thatuniquely identifies the token. In some embodiments, the transfer requestincludes a public key of the entity that digitally signed the token. Insome embodiments, the transfer request may include a public address ofthe token owner that is requesting to transfer the token.

The token holder may initiate the transfer of a token from the digitalwallet of the token holder. In some embodiments, transfers of tokens maybe performed via the platform 100. In these embodiments, the token ownermay initiate a transfer of the token by instructing the digital walletto send a transfer request to the token transfer system 402 (e.g., via aGUI of the digital wallet). In these embodiments, the token transfersystem 402 may receive the transfer request and may determine whetherthe token is a valid token, and whether the public address of the ownerand/or the recipient are valid. If the token is valid and the publicaddresses of the owner and/or the recipient are valid, the tokentransfer system 402 may transmit a copy of the token to a user deviceand/or account associated with the intended recipient. Once accepted bythe recipient, the token transfer system 402 may instruct the ledgermanagement system 104 to update the distributed ledger to indicate thechange of ownership of the token, such that the distributed ledgerindicates that the recipient is the current owner of the token.

Referring now to FIG. 7A, an illustration of a wallet 700 display isshown. The display of the wallet 700 includes a plurality of tokens,such as tokenized tokens 702 a-702 n (generally 702), non-fungibletokens 704 a-704 n (generally 704), and fungible tokens 706 a-706 n(generally 706). As can be seen, in embodiments, the tokens are groupedby token type. The tokenized tokens 702 may include displayed indicia703 communicating the type and, in embodiments, the amount of particularcontents 705 contained within the respective tokenized token 702. Forexample, the user's Bitcoin within the platform 100 may split among afungible token 706 a balance and one or more tokenized tokens 702 a.Moreover, the fungible Bitcoin 706 a may be a consolidated balance ofthe user's fungible bitcoin 706 a, or may be separate balances (e.g.,balance equal to amount of bitcoin transferred into the platform 100 ina single transaction).

The non-fungible tokens 704 may include display indicia to communicatepertinent information related to the token. For example, a plurality ofpurchasable skins 704 a, 704 b and work-for-hire 704 may be groupedtogether, and each may display indicia such as an image of the good. Thefungible tokens 706 a-706 n are tokens corresponding with fungiblegoods. For example, the fungible tokens 706 a-706 n may includecurrencies, cryptocurrencies, commodities, etc.

In embodiments, the digital wallet is configured to transmit the tokendirectly to a user device 190 or account (e.g., an email account, anaccount on a 3rd party messaging app), whereby the recipient of thetoken may accept the token. In some of these embodiments, the digitalwallet of the recipient may transmit a transfer request to the tokentransfer system 402 indicating a request to transfer the token to therecipient, in addition to sending a copy of the token to the intendedrecipient. In these embodiments, the token transfer system 402 maydetermine whether the token is a valid token and whether the publicaddress of the owner and/or the recipient are valid. If the token isvalid and the public addresses of the owner and/or the recipient arevalid, the token transfer system 402 may allow the recipient to acceptthe token into a respective digital wallet of the recipient. Onceaccepted by the recipient, the token transfer system 402 may instructthe ledger management system 104 to update the distributed ledger toindicate the change of ownership of the token, such that the distributedledger 310 indicates that the recipient is the current owner of thetoken.

Alternatively, in some embodiments, the digital wallet of the tokenowner does not transmit a transfer request to the token transfer system402. In these embodiments, the user device 190 of the recipient of atoken may present a mechanism by which the token owner may accept thetoken. For example, the user device 190 may present a link to accept thetoken. Upon the intended recipient accepting the token, the user device190 (e.g., via an instance of the digital wallet of the recipient) maytransmit the transfer request to the token transfer system 402. In thisscenario, the token transfer system 402 may determine whether the tokenis a valid token and whether the public address of the owner and/or therecipient are valid. If the token is valid and the public address of theowner and/or the recipient are valid, the token transfer system 402 mayinstruct the ledger management system 104 to update the distributedledger to indicate the change of ownership of the token, such that thedistributed ledger indicates that the recipient is the current owner ofthe token.

As discussed, in response to a transfer request, the token transfersystem 402 may determine whether the token is a valid token and whetherthe public address of the owner and/or the recipient are valid. Inembodiments, a token may be validated using a public key associated withthe token. For example, the token transfer system 402 may provide thetoken (or an indicator thereof) and a public key indicated in thetransfer request to the ledger management system 104. The ledgermanagement system 104 may determine whether the token identifier isstored on the distributed ledger, and if so, may verify that the publickey provided with the transfer request is the public key that was usedto digitally sign the token. In embodiments, the token transfer system402 may validate the identities of the recipient and/or the token ownerwishing to transfer the token using the public addresses thereof. Insome of these embodiments, the token transfer system 402 may provide thepublic address of the recipient and/or the public address of the tokenowner to the ledger management system 104, which may in turn look up therespective public address to verify that the public address is stored onthe distributed ledger. In response to determining that the token isvalid and the public addresses of the token owner and/or the recipientare valid, the token transfer system 402 may allow the transfer of thetoken and may instruct the ledger management system 104 to update thedistributed ledger to indicate the change of ownership of the token,such that the distributed ledger indicates that the recipient is thecurrent owner of the token.

In embodiments, the redemption system 404 allows an owner of a token toredeem the token. The redemption system 404 may receive a request toredeem (or “redemption request”) the token. The redemption request mayinclude the token or an identifier of the token (e.g., an alphanumericstring) and may include a public address of the user attempting toredeem the token. In embodiments, the redemption request may furtherinclude the public key used to digitally sign the token. In response toreceiving the redemption request, the redemption system 404 may providethe token, the public address of the user attempting to redeem thetoken, and the public key used to digitally sign the token to the ledgermanagement system 104. The ledger management system 104 may then eitherverify or deny the token/public address combination. The ledgermanagement system 104 may deny the combination if the token is not avalid token and/or the user is not the listed owner of the token. Theledger management system 104 may verify the token/public addresscombination if the token is deemed valid and the requesting user isdeemed to be the owner of the token.

In response to verifying the token/public address combination, theredemption system 206 may execute a workflow corresponding to thevirtual representation to which the redeemed token corresponds. Forexample, in some scenarios, the user may be redeeming a tokencorresponding to a digital item (e.g., a gift card, an mp3, a movie, adigital photograph). In these scenarios, the redemption system 404 maydetermine a workflow for satisfying the digital item. For example, theredemption system 404 may request an email address from the user or maylook up an email address of the user from the distributed ledger. Inthis example, the redemption system 404 may email a link to download thedigital item to the user's email account or may attach a copy of thedigital item in an email that is sent to the user's email account. Inanother scenario, the user may be redeeming a token corresponding to aphysical good (e.g., clothing, food, electronics, etc.) or a physicalservice (e.g., maid service). In the case of a physical good, theredemption system 404 may determine a workflow for satisfying thephysical item. For example, the redemption system 404 may present a GUIto the user that allows the user to enter shipping information of theuser. Alternatively, the redemption system 404 may look up the shippinginformation of the user from, for example, the distributed ledger or auser database. The redemption system 404 may then initiate shipment ofthe physical good. For example, the redemption system 404 (or alogistics system) may transmit a shipping request to a warehouse thathandles shipments of the good indicating the shipping information. Theforegoing are examples of how a token may be redeemed.

The redemption system 404 may execute additional or alternativeworkflows to handle redemption of a token. For example, in somescenarios the initial purchaser of the token may not have specifiedcertain parameters of an item that are needed to satisfy thetransaction. For example, if the item is clothing, the initial purchasermay not have specified the size and/or color of the item. In anotherexample, if the item is a food item, the initial purchaser may not havespecified side orders, toppings, drink choices, or the like. If the itemis an experience such as plane tickets or a hotel reservation, theinitial purchaser may not have specified dates of travel. In thesescenarios, the redemption system 404 may present a GUI that allows theredeemer of the token to specify the needed parameters, so that thetransaction may be specified. In response to receiving the parameters,the redemption system 404 may ascribe these parameters to the instanceof the virtual representation or to any other suitable data structurecorresponding to the satisfaction of the transaction (e.g., a deliveryorder, a purchase order, etc.), such that the transaction may besatisfied.

In embodiments, the transaction system 106 includes a digital walletsystem 408 that supports digital wallets. A digital wallet may be tokensthat are owned by an owner of the account associated with the digitalwallet and may provide a graphical user interface that allows the userto view, redeem, trade, transfer, gift, deposit, withdraw, or otherwisetransact with their tokens. In embodiments, the digital wallet system408 provides an instant sell capability, where users can agree to selltokens corresponding to items. For example, the instant sell capabilitymay allow a user to sell items at the rate of 90% of the floor price. Insome embodiments, other users may view some or all of the virtualrepresentation instances owned by the account owner, in accordance withthe user's privacy settings. Users may opt to hide or make privateindividual virtual representations or all virtual representations.

In some embodiments, the platform 100 and/or digital wallet of a usermay provide visual indicia that may be associated with the token whenbeing transferred to another person. For example, the visual indiciathat may be associated with a token may include emojis, images, gifs,videos, and the like. These visual indicia may be used by the user whentransmitting a token to another user. For example, if the tokencorresponds to a bouquet of flowers and the visual indicia is an emojiof a flower, the user may send the token in a message using the floweremoji. In this example, the user may access the token in the digitalwallet (e.g., via a native application on a user device 190) and mayselect an option to send the token to a recipient. The user may identifythe recipient (e.g., selecting from a list of contacts) and may beprovided an opportunity to type a message. The client application (e.g.,the digital wallet) may present a keyboard that includes the floweremoji, whereby the flower emoji represents the token. In response to theuser selection of the flower emoji and subsequent “sending” of thetoken, the digital wallet application may initiate transmission of themessage that includes the token/flower emoji. In this example, thedigital wallet may also transmit a transfer request to the tokentransfer system 402 indicating that the transferring user has requestedto transfer the token. The transfer request may include a copy of thetoken and a public address of the transferring user. In embodiments, thetransfer request may further include a public address or other indicator(e.g., an email address, a phone number, a user id, or the like) of theintended recipient of the token.

In embodiments, the transaction system 106 includes an express tradingsystem 410 in which users may trade one or more assets withoutexchanging money. In these embodiments, the express trading system 410provides a mechanism by which users can safely trade tokens, where eachtoken represents a different item. In an example operation, a first usermay make a trade offer in a smart contract to a second user to exchangeone or more tokens for one or more tokens in return. The second user mayaccept by transferring the requested virtual asset. The smart contractthen marks the transaction as completed. In embodiments, the expresstrade system 410 may provide a GUI that allows a user to view aninventory of tokens, create offers, accept offers, and/or cancel offers.

In embodiments, the transaction system 106 includes a paymentintegration system 412. The payment integration system 412 allows a userto purchase a token corresponding to an item. The payment integrationsystem 412 may accept credit cards, different forms of currency, and/orcryptocurrency.

In some embodiments, the transaction system 106 includes a subscriptionsystem 414. In these embodiments, users can subscribe to a service toreceive items that they consume regularly via the subscription system414.

In embodiments, the transaction system 106 includes a ledger bridgingsystem 416. The ledger bridging system 416 provides a framework tosecure or lock down an original virtual asset in a first decentralizedledger system (or any holder of currency, including traditional banks)and creating a tradeable duplicate in a second decentralized ledgersystem. In this way, users may fund their accounts on the tokenizationplatform 100 with different currencies and different transfer vehicles,and may then engage in transactions (e.g., trade, gift, or redeem) usingthe different currencies. In some embodiments, the decentralized ledgerbridging system 416 provides an escrow function across decentralizedledger systems (e.g., ledger systems that are separate and apart fromthe distributed ledgers 310 of the platform 100). In embodiments, theledger bridging system 416 or a digital wallet may provide a tokendeposit GUI and/or a token withdrawal GUI.

In embodiments, the ledger bridging system 416 allows a user to fundtheir account with one or more external currencies. For example, a usermay fund an account with Bitcoin, Ethereum coins, other suitablecryptocurrencies, and/or traditional currencies (e.g., U.S. Dollars,British Pounds, Euros, Chinese Yuan, Japanese Yen, and/or the like). Inthe case of cryptocurrencies, a user may facilitate a transfer ofcryptocurrency from an external account, for example, using anon-affiliated digital wallet that stores the user's cryptocurrency. Inthe case of traditional currencies, a user may transfer funds into hisor her account using, for example, a credit card, a direct moneytransfer, an ACH transfer, or the like. In some embodiments, when theuser transfers funds (cryptocurrency or traditional currency) into anaccount with the tokenization platform 110 (which may be referred to asa “funding transaction”), the ledger bridging system 416 may generate arecord corresponding to the funding transaction and may provide therecord to the ledger management system 104, which may update thedistributed ledger to reflect the funding transaction. The record mayindicate the account to which the funds were transferred, the accountfrom which the funds were transferred, an amount that was transferred, adate and time of the transfer, and/or any other suitable data.

Once an account is funded, a user can then use the transferred funds toparticipate in any transaction on the tokenization platform 100. In someembodiments, at least a subset of the transferred funds is tokenized ina manner that comports with the protocol supported by the tokenizationplatform 100 and/or the distributed ledger 312 corresponding thereto. Inembodiments, the ledger bridging system 416 may tokenize one or morecrypto coins (e.g., a bitcoin), any fraction of crypto coins, or anyamount of currency in response to a request corresponding to the user.The request to tokenize funds may be an explicit request or an implicitrequest. An explicit request may refer to when the user specificallyrequests the tokenization of a certain amount of currency. An implicitrequest may refer to when the user engages in a transaction on thetokenization platform 100 that implicates the transferred funds in theuser's account, such that at least a portion of those funds need to betokenized to facilitate the transaction (e.g., the user purchases anitem and elects to pay for the item using some of the transferred fundsin the user's account. Regardless of whether the request is implicit orexplicit, the ledger bridging system 416 may tokenize the certain amountof currency.

In some of these embodiments, the ledger bridging system 416 tokenizes aspecified amount of currency by minting a tokenized token that “wraps”the certain amount of currency. A tokenized token may refer to anon-fungible token that has attributes that define the type of currencyand an amount of currency represented by the coin (e.g., an amount ofbitcoin, Ethereum, dollars, pounds, or the like). In some of theseembodiments, a tokenized token may refer to a non-fungible token thathas a set of attributes defining characteristics of such token inaddition to having a set of fungible and/or non-fungible tokensrepresenting digital currency balance(s) enclosed within a tokenizedtoken and/or other digital item(s). In addition, tokenized token cancontain business rules governing redemption, transfer and othertokenized token lifecycle mechanisms. In some embodiments, the ledgerbridging system 416 mints the new token by requesting the generation ofa new token by the token generation system 302. The ledger bridgingsystem 416 may provide the type of currency, the amount of currency, andownership data (e.g., the account to which the new tokenized token willbelong) to the token generation system 302. In response, the tokengeneration system 302 generates a tokenized token, for example, in themanner described above. In this way, the token generation system 302treats the currency as an “item.” In this way, a tokenized token may beexchanged (e.g., for other tokenized tokens or tokenized items), gifted,and/or redeemed. In some embodiments, the types of transactions that atokenized token may participate in may be restricted. For example,tokenized tokens representing unstable currencies may be restricted frombeing exchanged but may be redeemed or gifted.

In embodiments, the ledger bridging system 416 further generates avisual indicium corresponding to the tokenized token as part of theminting process. In some embodiments, the visual indicia is a digitalsticker (or “sticker”). For example, in some embodiments, the stickermay depict an amount and a symbol representing the currency (e.g., asticker representing a tokenization of five dollars may depict “$5”, ora sticker representing a tokenization of a tenth of a bitcoin may depict“B5”). In this way, the sticker may be displayed in a wallet of an ownerof the tokenized token. As discussed, the visual indicia may be used toconvey to a user the tokenized tokens that the user owns. Additionally,in some embodiments, the visual indicia may be used to transfertokenized tokens to other parties (e.g., via text message, messagingapplications, email, and the like), as is described elsewhere in thedisclosure.

In some embodiments, the ledger bridging system 416 may instantiate (orrequest the instantiation of) a smart contract corresponding to thetokenized token as part of the minting process. In these embodiments,the smart contract may define one or more base functionalities thatgovern the tokenized token lifecycle mechanisms such as ownershiptransfer and/or redemption logic. The base functionalities may includethe ability to change ownership of the tokenized token, the types oftransactions in which the tokenized token may be used (e.g., to makepurchases, to gift, to exchange, to redeem for cash, etc.), and thelike. Upon a new tokenized token being minted, the ledger bridgingsystem 416 may instantiate an instance of the smart contractcorresponding to the newly minted tokenized token. The instance of thesmart contract may execute each time the tokenized token is involved ina transfer (e.g., exchanged, gifted, or redeemed). For example, eachtime an owner of the tokenized token requests to transfer the tokenizedtoken, the instance of the smart contract may be implicated by therequest and the instance of the smart contract can either disallow orfacilitate the transfer depending on the contents of the request and thesmart contract.

Once a tokenized token is minted, the funds represented by the tokenizedtoken may be “escrowed” by the ledger bridging system 416. In this way,the user is prevented from removing funds from his or her account untilthe tokenized token is redeemed. In some embodiments, the ledgerbridging system 416 may transfer the funds corresponding to thetokenized token from the account of the user to a designated escrowaccount. Alternatively, the ledger bridging system 416 may freeze thefunds corresponding to the tokenized token, such that the funds may notbe transferred by the user until the tokenized token is redeemed. Once atokenized token is redeemed, the funds represented by the tokenizedtoken may be released from escrow, deposited into the account of theredeeming user, and the tokenized token may be destroyed (also referredto as being “invalidated”).

In embodiments, the ledger bridging system 416 updates, or initiates theupdate of, the distributed ledger. The distributed ledger may be updatedupon a number of different occurrences. As discussed, in embodiments,the distributed ledger may be updated when a user initially funds anaccount. In embodiments, the ledger bridging system 416 updates (orinitiate the update of) the distributed ledger upon a new tokenizedtoken being minted. In these embodiments, the distributed ledger isupdated to reflect the existence of the new tokenized token and theownership of the token. In embodiments, the ledger bridging system 416updates (or initiate the update of) the distribute ledger with theinstance of the smart contract corresponding to the tokenized token. Inembodiments, the ledger bridging system 416 may update (or initiate theupdate of) the distributed ledger each time a tokenized token istransferred. In these embodiments, the distributed ledger may be updatedto reflect the new owner of the tokenized token. In embodiments, theledger bridging system 416 may update (or initiate the update of) thedistributed ledger when a tokenized token when the token is redeemed andsubsequently destroyed. In these embodiments, the distributed ledger maybe updated to reflect that the tokenized token is no longer valid, theaccount that redeemed the token, and/or when the token was redeemed.

FIG. 5 illustrates the intelligence and automation system 110 accordingto some embodiments of the present disclosure. In embodiments, theplatform includes an intelligence and automation system 110. Theintelligence and automation system 110 may include a machine learningsystem 502, an artificial intelligence system 504, a recommendationengine 506, a service matching engine 508, an advertising system 508,and/or a notification system 510.

In embodiments, the machine learning system 502 may trainmachine-learning models based on training data. Examples of machinelearned may include various types of neural networks, regression-basedmodels, hidden Markov models, scoring models, and the like. The machinelearning system 502 may train models in a supervised, semi-supervised,or unsupervised manner. Training can be done using training data, whichmay be collected or generated for training purposes. The machine learnedmodels may be stored in a model datastore.

In an example, the machine learning system 502 may be configured totrain a gift prediction model. A gift prediction model (or predictionmodel) may be a model that receives recipient attributes (e.g., aprofile relating to an intended recipient) and/or item attributes of oneor more items that may be provided as a gift and that outputs one ormore predictions regarding sending a gift token to that particularconsumer. Examples of predictions may be whether to send a gift to thatuser, gifts the user would value, and the like. In embodiments, themachine learning system 502 trains a model based on training data. Inembodiments, the machine learning system 502 may receive vectorscontaining user data (e.g., transaction history, preferences, wish listvirtual assets, and the like), virtual asset data (e.g., price, color,fabric, and the like), and outcomes (e.g., redemption, exchanges, andthe like). Each vector may correspond to a respective outcome and theattributes of the respective user and respective item. The machinelearning system 502 takes in the vectors and generates predictive modelbased thereon.

In embodiments, the machine learning system 502 trains risk scoringmodels using training data sets that indicate the features of usersparticipating in a transaction, features of the transaction (e.g., thetype of transaction (e.g., purchase, loan, sale, etc.), the size of thetransaction (e.g., a dollar amount), and the like), and an outcome ofthe transaction indicating whether the transaction was successful orunsuccessful (e.g., did the buyer pay for the item after purchase, didthe borrower pay the loan off or default on the loan, was the purchaseditem delivered and in sufficient condition, etc.). The training datasets may be based on transactions facilitated by the platform and/orgenerated by an expert.

In embodiments, the machine learning system 502 may store the predictivemodels in a model datastore. In embodiments, the machine learning system502 may be further configured to update a model based on capturedoutcomes, which is also referred to as “reinforcement learning.” Inembodiments, the machine learning system may receive a set ofcircumstances that led to a prediction (e.g., item attributes and userattributes) and an outcome related to the treatment (e.g., redemption ofitem, exchange of item, refund of an item), and may update the modelaccording to the feedback. As used herein, the machine learningtechniques that may be leveraged by the machine learning system include,but are not limited to, decision trees, K-nearest neighbor, linearregression, K-means clustering, deep learning neural networks, randomforest, logistic regression, Naïve Bayes, learning vector quantization,support vector machines, linear discriminant analysis, boosting,principal component analysis, and hybrid approaches.

In embodiments, the artificial intelligence (AI) system 504 leveragesthe machine-learned models to make predictions or classificationsregarding purchasing, gifting, or other e-commerce outcomes with respectto user data and asset data. Examples of predictions include whether auser will purchase an item, whether a user will exchange a gifted item,redemption options such as delivery timing and delivery location, andthe like. For example, the AI system 504 may leverage a gift predictionmodel to make predictions as to whether a recipient of a particular itemwill like a gift, return a gift, or exchange a gift.

In embodiments, the recommendation system 506 may be configured toprovide recommendations to users regarding items. The recommendationsystem 506 may request a recommendation from the AI system 504 based onattributes of a user. The AI system 504 may output a set ofrecommendations and the recommendation system 506 may provide therecommendations to the user or another party. For example, therecommendation system 506 may provide users with recommendations ofitems to purchase based on a purchase history of the user.

In embodiments, an advertising system 508 is configured to determineadvertisements to display to a user, where the advertisements relate toitems that are offered for transaction on the platform. In embodiments,the advertising system 508 may present users with discounts, promotions,and the like.

In embodiments, a services-matching system 510 is configured to matchconsumers to service providers for user-selected services. In theseembodiments, a user may be seeking service, and the service matchingsystem 510 may identify service providers that are best suited toprovide the service. For example, the services matching system 510 maymatch service seekers and service providers based on pricing,availability, location, and the like.

FIG. 6 illustrates the intelligence and automation system 110 accordingto some embodiments of the present disclosure. In embodiments, theanalytics and reporting system 112 is configured to capture and reportanalytics relating to various aspects of the e-commerce platform 100. Inembodiments, the analytics and reporting system 112 may include ananalytics system 602, a reporting system 604, and/or a regulated assetsystem 606. In embodiments, the analytics and reporting system 112 mayprovide an analytics interface that allows a user to access theanalytics and reporting system 112.

In embodiments, the analytics system 602 may track and analyze datarelating to, but not limited to, consumer data, item data, merchant,manufacturer, or provider data; user behavior (e.g., purchase behavior,telemetric, and the like), and transaction events (e.g., when items arepurchased, how items are purchased, how items are transferred, and thelike).

In embodiments, the reporting system 604 reports analytics gained by theanalytics system 602 to one or more parties. Interested parties mayaccess the reporting system 604 and/or may subscribe to receiveanalytics reports. The reporting system 604 may be configured togenerate reports based on the gathered analytics and to provide thereports to interested parties. In embodiments, a regulatory GUI may thenallow regulators to access the platform 100. For example, a regulatormay access the platform to track and monitor a regulated item, such as3D printed firearms.

In embodiments, the analytics and reporting system 112 includes aregulated asset system 606. In embodiments, the regulated asset system606 is configured to manage regulated items. For example, the regulatedasset system 606 may manage access to weapons or firearms,pharmaceuticals, alcohol, tobacco products, food products, event/venueentry, airline tickets, and the like. In embodiments, the regulatedasset system 606 may track and monitor transactions regarding regulateditems and may notify certain regulatory agencies based on thetransactions and a corresponding workflow. In a non-limiting example, atoken could be used to track a 3D printed firearm, where the item thatis purchased would be the model used to print the firearm.

Referring back to FIG. 1, in embodiments, the platform 100 includes avirtual world presence system 114 for representing tokenized physicalworld items within virtual world environments. In some embodiments, thevirtual world environments may depict virtual world avatars. Virtualworld avatars may represent a user (e.g., a potential buyer) and mayinteract with virtual items in a virtual world environment. Users may“shop” by controlling a virtual world avatar in a virtual world store.For example, a virtual world avatar may try on a virtual representationof a tokenized physical world hat in a virtual world dressing room. Insome embodiments, the virtual world presence system may include avirtual reality system that provides a framework for displaying thevirtual world environment. In embodiments, the virtual world presencesystem may also include a virtual asset display system that displaysitems related to a user, including but not limited to: items that areowned by the user, in the custody of the user, desired by the user, andthe like. These items can be displayed publicly to other users or hiddenfrom other users, individually or collectively. In some embodiments, thevirtual asset display system may determine the set of tokens owned by auser to determine the items that are owned or possessed by a user.

In embodiments, the virtual world presence system 114 may include acontent sharing system that allows sharing of content related to virtualassets to content platforms. The content sharing system enables users toshare content related to virtual assets owned by a user or in custody ofuser or desired by user. Users may obtain additional information about avirtual asset or request to purchase, rent, borrow, trade, or the like.The shared content may include data from the virtual world presencesystem. For example, a user may share a video of the user's associatedvirtual world avatar eating a virtual pizza in a virtual pizza parlor.

Referring now to FIG. 8, the tokenization platform 100 may support anumber of different applications and/or provide a number of differentservices. For example, the platform 100 may support collateralizedlending applications, authentication services, “mystery box”applications, casino-gaming services, and video game streaming services.

In embodiments, the platform 100 includes a collateral management system802. In embodiments, the collateral management system 802 allows aborrower to provide collateral and request a loan. In some of theseembodiments, a user wishing to borrow money can take a collateral item(e.g., a collectible item, jewelry, a firearm, a precious metal, or thelike) to a facility affiliated or otherwise supported by the platform100. At the facility, an employee at the facility may inventory thecollateral item using an interface provided by the collateral managementsystem 802. Inventorying the collateral item may include requesting anitem identifier for the collateral item, associating the item identifiercollateral item with an account of the user (i.e., the owner of thecollateral item), taking high resolution photographs of the collateralitem, weighting the collateral item using a scale, entering adescription of the collateral item, an appraisal of the collateral item,and the like. Once inventoried, the collateral management system 802 cancreate a virtual item representing the collateral item, and then maygenerate a non-fungible token corresponding to the virtual item (whichmay be referred to as a “collateral token”). For example, the collateralmanagement system 802 may request the generation of the virtual item andthe collateral token from the ledger management system 104. Upon thecollateral token being generated, the ledger management system 104 mayupdate the distributed ledger to reflect the new collateral token andthe ownership of the collateral token by the borrower. The collateraltoken may then appear in a digital wallet of the borrower. In someembodiments, the collateral token may be represented by a visualindicium in the digital wallet. The collateral item corresponding to thecollateral token may be stored at the facility until the collateraltoken is redeemed. Once redeemed, the redeeming user (the borrower or atransferee of the collateral token) may pick up the collateral item fromthe facility or the collateral item may be shipped to thereto.

In embodiments, the collateral management system 802 may allow aborrower to seek a loan using the collateral token. In embodiments, thecollateral management system 802 may provide a marketplace (e.g., thatis accessible via a graphical user interface) where the borrower canrequest a loan amount and offer the collateral token as collateral.Lenders (who have accounts with the tokenization platform 100) may thenmake loan offers to the borrower via the marketplace. In exampleembodiments, the loan offers may specify a loan amount, an interestrate, and a loan length. The loan offers may include additionalconditions as well. For example, a loan offer may indicate whether theloan can be sold to another lender, and if so, a payoff amount to bepaid to the original lender. The borrower may shop through the loanoffers and may ultimately decide on a loan offer to accept.

Once the borrower accepts an offer, the collateral management system 802may instantiate an instance of a loan smart contract that memorializesthe term of the loan and may escrow the collateral token (e.g., no onecan redeem the collateral token or transfer the collateral token withoutcomplying with the smart contract). In escrowing a collateral token, thecollateral management system 802 (or the loan smart contract) maydeposit the collateral token into an escrow account, such that no partyin the transaction has ownership rights to the collateral token while itis in the escrow account. Such an action will lock the collateral tokenuntil the loan is paid off or the underlying item is liquidated. Inembodiments, the loan smart contract may indicate the lender, theborrower, the locked collateral token (and an address thereof), the loanamount, a payment schedule, whether the loan is transferrable, when theloan is considered to be in default, ownership rights of the collateraltoken upon default, and the like. The ledger management system 104 mayupdate the distributed ledger to reflect the loan smart contract.

Once the instance of the smart contract is instantiated, the borrowermust commence repayment of the loan according to the loan schedule. Itis appreciated that the loan schedule may require a single lump sumpayment by a given time or may require multiple payments that are to bemade at predetermined intervals. In embodiments, the borrower may makepayments to the lender via his or her digital wallet. In theseembodiments, the borrower may transfer funds from a bank, credit card, adigital wallet holding other currencies, or the like. The borrower maythen transfer those funds to the lender via the digital wallet. In someembodiments, the ledger bridging system 416 facilitates the transfer offunds from the account of the borrower to an account of the lender.

In embodiments, the collateral management system 802 may deploy alistening thread corresponding to an instance of a smart contractgoverning a loan. A listening thread may listen for payments by theborrower defined in the instance of the smart contract. When a paymentis made, the listening thread may notify the ledger management system104, which updates the distributed ledger to reflect the payment. Duringthis update, the instance of the smart contract governing the loan isprovided a notification indicating the payment event, which may causethe smart contract to determine whether the loan is fully repaid. If theloan is fully repaid, the smart contract releases the collateral tokento the borrower, bringing the smart contract to a close. If the loanamount is not repaid, the terms of the smart contract (e.g., the loanamount and the next repayment) may be updated based on the payment. Ifthe listening thread does not detect a receipt of a payment before thepayment due date, the listening thread may notify the ledger managementsystem 104 of the missed payment. In response to the notification, theledger management system 104 may update the distributed ledger toreflect the non-payment, which may cause the smart contract to determinewhether the loan is in default according to the terms of the contract.If the loan is determined to be in default, then the smart contracttransfers ownership of the collateral token to the party specified bythe smart contract (e.g., the lender). Once this occurs, the lender mayredeem the collateral token, sell the collateral token, gift thecollateral token, or exchange the collateral token, as the lender is nowthe owner of the collateral token.

In embodiments, the collateral management system 802 may provide amarketplace for loans that may be bought or transferred. The marketplacemay present the amount due on a loan, the value of the loan (e.g., theamount that is to be collected when fully paid off), the payment historyof the loan (e.g., whether the borrower is making or missing payments),the collateral item that secures the loan, the price to purchase theloan, and the like. In some embodiments, potential lenders may opt topurchase the loan from the current lender. In these embodiments, thepurchase of the loan causes the collateral management system 802 toterminate the current smart contract and to instantiate a new smartcontract to reflect the new owner or to adjust the smart contract, suchthat payments will be directed to an account of the new lender and todesignate the new lender as the destination of the collateral tokenshould the borrower default. Additionally, or alternatively, theborrower may seek better terms on a loan using the marketplace. Assuminga loan is transferrable, the borrower may list the loan on themarketplace whereby potential lenders can view the borrower's paymenthistory, the remaining balance on the loan, the loan payoff amount, andthe collateral item. Potential lenders may then make loan offers to theborrower with each loan offer having its terms. The borrower can accepta loan offer. In response to the borrower accepting the loan offer, thenew lender must transfer the loan payoff amount to the previous lender,which causes the collateral management system 802 to terminate thecurrent smart contract and to instantiate a new instance of a smartcontract in accordance with the newly accepted terms of the loan offer.

In embodiments, the platform 100 includes an authentication system 804.The authentication system 804 may provide authentication and/orappraisal support services on behalf of the platform 100. In someembodiments, the authentication system 804 may be used to authenticatean item that is offered for sale or provided for collateral.Additionally, or alternatively, the authentication system 804 may beused to obtain an appraisal of an item that is offered for sale orprovided for collateral.

In some embodiments, the authentication system 804 presents a portalthat allows a user (e.g., a seller or an employee of a facility thatholds items) to upload a virtual representation of an item. The user mayprovide an item classification (e.g., a baseball card, vintage clothing,jewelry, artwork, or the like), and one or more of: one or more highresolution photographs of the virtual item; a 3D representation of theitem; dimensions of the item; a weight of the item; and/or the like. Theauthentication system 804 may allow domain-specific experts to sign upas authenticators/appraisers, such that a domain-specific expert canauthenticate and/or appraise items classified in the area of theirexpertise. For example, sports memorabilia experts may be allowed toauthenticate baseball cards and memorabilia, but not jewelry or artwork.In some embodiments, authenticators may be rated within their area ofexpertise and for sub-domains within their area of expertise (e.g.,within the general category of sports memorabilia, an expert can berated with respect to their knowledge on baseball memorabilia,basketball memorabilia, football memorabilia, and the like). When a newitem is entered into the portal, the domain-specific experts can bid onthe appraisal/authentication job, whereby the bid indicates the terms(e.g., price) under which the expert will perform theappraisal/authentication job. A user may then select the one or more ofthe experts based on their respective bids and/or their ratings.Alternatively, the authentication system 804 may select the one or moreof the experts based on their respective bids and/or their ratings. Oncean expert wins a bid, the expert performs the authentication and/orappraisal based on the information uploaded by the user (e.g., one ormore high resolution photographs of the virtual item, a 3Drepresentation of the item, dimensions of the item, a weight of theitem, and/or the like). The expert may provide an appraisal value and/ora determination indicating the authenticity of the item. Theauthentication system 804 may include the expert's appraisal and/orauthenticity determination in the virtual representation of the virtualitem and, in some embodiments, the authentication system 804 may updatethe distributed ledger with the expert's appraisal and/or authenticitydetermination. As can be appreciated, the appraisal and/or theauthenticity determination may result in an item being kept on orremoved from the platform or may impact the ability to collateralize aloan using the item.

In some embodiments, the authentication system 804 requires an expert toprovide appraisal/authentication notes that indicate the reasons for theexpert's determination. In providing an appraisal and/or providing adetermination of authenticity, the expert provides one or more reasonsfor his or her findings. For example, in opining that a particular shoeis a knockoff, an expert may indicate in the notes that the stitching ofthe shoe is indicative of a knockoff. The authentication system 804 mayinclude the expert's appraisal/authenticity notes in the virtualrepresentation of the virtual item and, in some embodiments, theauthentication system 804 may update the distributed ledger with theexpert's appraisal/authenticity notes.

In embodiments, the expert authentication determinations, as well asauthentication notes may be used by the machine learning system 502(FIG. 5) to train one or more models that can determine whether an itemis likely a fake. In these embodiments, the models can be trained onimages, weights, dimensions, and/or other features of items that weredeemed to be fake. The authentication system 804 may leverage thesemodels (via the artificial intelligence system 804) to determine whethera new item is likely fake. If the model classifies the item as beinglikely fake, the authentication system 804 may include the determinationin the virtual representation of the virtual item and, in someembodiments, the authentication system 804 may update the distributedledger with the determination that the item is likely fake. If the modelis unable to classify the item as likely being fake, the authenticationsystem 804 may list the item on the portal, such that experts may assessthe item's authenticity. It is noted that in embodiments, a model canclassify an item as likely being fake, but only an expert mayauthenticate the item, as counterfeiters may adapt and improve thequality of the counterfeit items to trick the models into issuing falseauthentications.

In some embodiments, the collateral management system 802, theauthentication system 804, and the ledger management system 104 may beconfigured to support a securitized decentralized loan process. Exampleimplementations of the securitized decentralized loan process aredescribed throughout the disclosure, including with reference to FIGS.XXX.

In embodiments, the tokenization platform 100 includes a mystery boxsystem 806 that supports a mystery box game. In embodiments, a “mysterybox” may refer to a set of tokens that potentially can be won by aplayer, where each token represents a different item that can beredeemed using a token. In embodiments, each token may have a differentprobability of being selected. In some embodiments, each token may beassigned a range of numbers, where the range of numbers for each tokenreflects the probability of being won by a player. For example, if thereare three tokens, where the first token has a 10% chance of being won,the second token has a 20% chance of being won, and the third token hasa 30% chance of being won, and there is a 40% chance of no token beingwon, the first token may be assigned 1-10, the second token may beassigned 11-30, and the third token may be assigned 31-60. In thisexample, the range of values that may be selected would be 1-100. Aplayer may pay for a chance to win an item in the mystery box. In someembodiments, the odds of winning each token, and the item represented bythe token, are depicted in relation to the mystery box. In this way,players are informed on their chances of winning the various items.

In response to the receiving payment from the player, the mystery boxsystem 806 may generate a random number that is bound by the overallrange of values for the box (e.g. 1-100). The mystery box system 806 maythen determine which token, if any, was won by the player based on therandom number. For example, a mystery box may be jewelry-themed, wherebythe mystery box includes a first token representing a diamond ring, asecond token representing a cubic zirconium ring, and eight tokens, eachrepresenting a $25 gift card that can be spent at a specific jewelryshop (e.g., the jewelry shop that provided the rings). In this example,the first token may have a 0.1% chance of being won, the second tokenmay have a 4.9% chance of being won, and the gift cards may each have a10% chance of being won, whereby there is a 15% chance that the playerwill not win a prize. In this example, the range of numbers may be1-1000, where the first token corresponds to the number 1, the secondtoken corresponds to the range of 2-50, and the third through eighthtokens have a collective range from 51-850. In this example, the priceto play may be set by the jewelry shop, such that the gift cards may beconsidered a mechanism to drive traffic to the jewelry shop. It is notedthat in the foregoing example, the range of tokens are sequential,however the ranges do not need to be sequential and can be slotted inany suitable manner.

In embodiments, the mystery box system 806, in response to a playerwinning a prize from the mystery box, may transfer the token to anaccount of the winning player. In these embodiments, the won token mayappear in the digital wallet of the player. Alternatively, the mysterybox system 806 may deliver the won token to the user via an electronicmessage (e.g., a text message, a messaging app message, an email, or thelike). As will be discussed below, in some embodiments, the mystery boxsystem 806 provides service to brick-and-mortar casinos, such that themystery box game is implemented in a physical device. In theseembodiments, the mystery box system 806 may print out a ticket that hasa token identifier of the won ticket (e.g., a QR code).

In embodiments, the mystery box system 806 may allow players to select amystery box to play from a plurality of available mystery boxes, whereeach mystery box may have a respective theme. For example, a firstmystery box may be art themed such that the mystery box contains tokenscorresponding to art-related items (e.g., arts of work, art relatedproducts, services relating to art (e.g., a commissioned painting by anartist), and the like); a second box may be entertainment themed, wherethe second box may contain tokens corresponding to a movie andtelevision-related items (e.g., memorabilia items from popular moviesand/or TV shows, DVDs or download codes for movies and/or TV shows, giftcertificates to movie theaters, and the like); a third box may be sportsthemed, where the third box may contain tokens corresponding tosports-related items that correspond to a particular team (e.g., gameworn apparel, tickets to games, replica apparel, team apparel, and thelike); a fourth box may be gaming themed, where the fourth box maycontain tokens corresponding to gaming-related items (e.g., video gamesystems, video games, gift certificates, upgrades for characters of aparticular game, and the like); a fifth box may be music-themed, wherethe box may contain tokens relating to items that correspond to aparticular band or artist (e.g., a signed show poster, memorabilia fromthe band or artist, tickets to a show, download codes for an album orsong, and the like); and so forth. In this way, players may select toplay for prizes that are enticing to them.

In embodiments, a mystery box may contain tokens corresponding toreplenishable items and/or non-replenishable items. Replenishable itemsare items that can be replenished in the mystery box when a player winsa token representing the item. For example, gift certificates, movietickets, sports game tickets, DVDs, electronics, video games, replicajerseys, and most clothing items are replenishable, while items such aswatches, high-end jewelry, game-worn sports apparel, signed memorabilia,limited edition shoes, original artwork, are examples ofnon-replenishable items. In some embodiments, the party offering themystery box may designate replacement items of similar value for thenon-replenishable items in a mystery box, such that when anon-replenishable item is won from the mystery box, it may be replacedby one of the designated replacement items. In some of theseembodiments, a mystery box may be arranged according to a “recipe.” Arecipe designates two or more tiers of items in the mystery box, and foreach tier the odds for winning an item from the tier. In theseembodiments, the provider of the mystery box may provide a list of itemsthat belong to each tier. For example, the highest tier (e.g., the tierwith the lowest odds) may include the high-value non-replenishableitems, while the lower tiers may include various levels of replenishableitems. Each item in the recipe may be tokenized, such that the tokensare reserved for use in the mystery box. Each time an item from a tieris won by a player, the mystery box system 806 may replace the tokenrepresenting the item with another token from the same tier as the wontoken. In this way, the price to play the mystery box and the oddsassociated with each item in the mystery box do not change when anon-replenishable item is won from the mystery box.

In embodiments, each mystery box is governed by a smart contract. Thesmart contract may define the different items or tiers of items, and foreach respective item or tier of items, odds for winning the respectiveitem. When a new mystery box is created, the mystery box system 806 mayinstantiate a new smart contract corresponding to the new mystery box.The instance of the smart contract may define the items or tiers ofitems of the new mystery box, the odds for each item (or tier of items),the token identifiers of each of items in the mystery box (orreplacement items that can be included in the mystery box), and a priceto play the mystery box. In embodiments where items are not replaced ina mystery box, the smart contract may further define the manner by whichthe odds of items or the price of the game may be adjusted when certainitems are exhausted. For example, if the highest value item in themystery box is won, the price to play the game may be lowered and/or theodds of winning the remaining items may be adjusted.

The mystery box system 806 may serve the mystery box game in a varietyof different manners. In embodiments, the mystery box system 806 mayserve the mystery box game via the tokenization platform 100, wherebyusers of the tokenization platform 100 may play the mystery box game ona website or application provided by the tokenization platform 100.Additionally, or alternatively, the mystery box system 806 may serve themystery box game to users via a third-party website or application. Inthese embodiments, the third-party website or application may access themystery box system 806 via the API system 108 of the tokenizationplatform 100.

In some embodiments, the mystery box system 806 may support casino-stylemachines, whereby players can play the mystery box game on a physicalmachine located at, for example, a casino or any other suitablebrick-and-mortar location. In these embodiments, the items may belocated at the brick-and-mortar location where the physical device islocated, such that when a player wins an item from the mystery box, theplayer may redeem the token at the brick-and-mortar location. In theseembodiments, the tokenization platform 100 includes the mystery boxsystem 806 that supports mystery box games that are played at thebrick-and-mortar locations. In these embodiments, the mystery box system806 may provide an API that allows network-connected physical gamingdevices to communicate with the tokenization platform 100. The mysterybox system 806 may serve the mystery box game to the physical gamingdevices via the API system 108. In embodiments, the mystery box system806 may provide token identifiers of won tickets, such that the physicalgaming devices may print a ticket that indicates the won token. In someembodiments, the ticket may include a QR-code that indicates the wontoken.

In embodiments, the player may redeem a ticket indicating a won token atthe brick-and-mortar location. In these embodiments, thebrick-and-mortar location may include scanning devices that scan thetickets and communicates the token identifier of the won token to thecasino gaming system. In response to receiving the token identifier ofthe won token, the mystery box system 806 may redeem the won token onbehalf of the player and may communicate a verification of theredemption of the won token to the scanning device. An employee usingthe scanning device may then provide the item won by the player to theplayer. Alternatively, the player may add the won token to a useraccount of the player. In these embodiments, the player may scan theticket (e.g., the QR-code). In response to the player scanning theticket, the mystery box system 806 may facilitate the transfer of thetoken to an account of the player, whereby the ticket may appear in theplayer's digital wallet. Once this occurs, the player may redeem, sell,gift, collateralize, or otherwise transact with the token.

In embodiments, the tokenization platform 100 includes a video gameintegration system 808. The video game integration system 808 allowsvideo game makers to place tokens in video games, such that gamesplaying a video game may be able to find, buy, trade, or otherwiseinteract with tokens in the video game. In embodiments, a video gamemaker may access an API of the tokenization platform 100 via the APIsystem 108, such that instances of a video game may request certaintokens or types of tokens from the tokenization platform 100. Inresponse to the request, the video game integration system 808 may servea token to the instance of the video game. The tokens may be fungible ornon-fungible. In the latter case, a token may be obtained, purchased, orotherwise transacted for by multiple video games. In the case of anon-fungible token, the first user to transact for the token is theowner of the token. In response to a user transacting for a token, thevideo game integration system 808 may update the distributed ledger toreflect the new ownership of the token.

In some example embodiments, a video game maker may allow third-partiesto advertise items for sale in a video game, whereby a user may purchasean item by selecting an icon (or other visual indicia) displayed in thevideo game that represents a token corresponding to the item. Forexample, an advertiser representing a pizza delivery chain may wish tooffer pizza delivery to gamers in a specific location. In this example,instances of the video game may request food-related tokens from thevideo game integration system 808, whereby each request indicates alocation of the device executing the respective instance of the videogame. The video game integration system 808 may identify tokenscorresponding to food items that can be delivered to a location where arespective instance of the video game is being executed. For example,the video game integration system 808 may identify tokens havingassociated metadata that indicates a delivery radius that includes alocation indicated in the request. In response to the request, the videogame integration system 808 serves the identified token to therequesting instance of the video game. A visual indicium representingthe token may then be displayed by the instance of the video game,whereby a user (i.e., video game player) may opt to transact for thetoken. Upon a user transacting for ownership of the token, the videogame integration system 808 updates the ownership data of the token toreflect that it is owned by the user. In scenarios where deliveryinformation or other logistical information are needed, the instance ofthe video game and/or the user can provide those details at the time oftransaction or the user can provide the required information to completethe transaction. For example, if the user elects to buy a pizza tokenfrom a pizza delivery chain, the instance of the video game and/or theuser may provide the address to where the pizza will be delivered. Theuser, via the instance of the video game, may also provide details suchas toppings for the pizza.

In some example embodiments, the video game maker may allow an itemrepresented by a token to be both used in the digital environment of thevideo game and to be redeemed in “real-life.” In these embodiments, thevideo game maker may include specific fungible or non-fungible tokens inthe video game, whereby users can find, buy, trade for, or otherwisetransact for the tokens appearing in the video game. Once a tokenappearing in a video game is transacted for, the video game integrationsystem 808 may update the ownership data of the transacted for the tokento reflect that the user is the owner of the token. A visual indicium ofthe token may appear in a video game instance corresponding to the userand/or in a digital wallet of the user. Once owned by the user, the usermay use the token in the video game and may subsequently redeem thetoken to receive the physical item represented by the token. Forexample, in a role-playing game a token may represent a pair of earringsthat give the player of the video game a special power (e.g.,invisibility). The user may use the earrings in the game to enjoy thespecial power or may redeem the earrings. In the latter scenario, theearrings may be shipped to the user, such that the earrings may bephysically worn by the user but are no longer able to be used in thevideo game. In some of these embodiments, the video game maker may allowthe user to transact the tokens. For example, the owner of a token maytrade or sell the token for a token corresponding to another item. Eachtime the ownership is changed, the video game integration system 808 mayupdate the distributed ledger to reflect the change in ownership. Once auser no longer owns a token, the user cannot use or redeem the itemindicated by the token. In some embodiments, the video game may allowthe user to return the item to a verified location (e.g., storagewarehouse), whereby once the item is authenticated the user may then usethe digital representation of the item in the video game once again.

The video game integration system 808 may allow video game makers tointegrate tokens into their video games in additional or alternativemanners. For example, video game makers may use tokens as “Easter eggs”or prizes that may be won by players as they uncover the tokens. Inanother example, a video game maker may integrate one or more mysteryboxes in a video game. In another example, users may create digitalitems within the construct of a video game, such that the digital itemsmay be tokenized and transacted for (e.g., traded, gifted, sold, etc.).

In embodiments, the tokenization platform 100 includes a useracquisition system 810. In embodiments, the user acquisition system 810provides mechanisms that facilitate the promotion of the tokenizationplatform, and particularly, the enlisting of new users. In someembodiments, the user acquisition system 810 provides each existing userwith a unique referral code that each respective user can share with hisor her friends, social media followers, contacts, or the like. Inaddition, the user acquisition system 810 may provide an incentive toeach existing user, whereby the incentive indicates a reward for eachnew user or number of users (e.g., three users) that sign up for anaccount. The incentive may be any form of payment, including currency(e.g., traditional currency or cryptocurrency), gift cards, physicalitems, digital items, and the like. In some embodiments, the reward isprovided as a tokenized token, whereby the tokenized token represents aset amount of currency. In embodiments, the user acquisition system 810may provide different incentives to different users. In someembodiments, the incentive may be determined based on the potentialreach of each respective user. For example, users that have significantreach (e.g., social media influencers, celebrities, etc.) may be givengreater incentive than users with relatively little reach. In someembodiments, the incentive may be determined based on the interests ofeach respective user. For example, a first user that is interested ingolf may be incentivized with golf-related items or gift certificates,while a second user that is interested in art may be incentivized withart-related items or gift certificates. In some embodiments, the useracquisition system 810 codifies the incentive for each user in arespective instance of a smart contract. In some of these embodiments,the smart contract instance governs the incentives/rewards of a user isassociated with the referral code of the user and/or the public addressof the user. When the referral code of the user is successfully used toenlist a new account, the smart contract may facilitate the transfer ofa token representing the reward to an account of the referring user.

Each time a new user enlists for an account using a referral code, theuser acquisition system 810 determines whether the new user islegitimate (e.g., not a bot, not a fraudulent account, etc.). Assumingthe new user is granted an account (e.g., there is not detected fraud),the user acquisition system 810 determines the user account associatedwith the referral code. In some embodiments, the user acquisition system810 determines a smart contract associated with the user account and/orthe referral code. The user acquisition system 810 may provide anotification to the smart contract associated with the user accountand/or the referral code of a new account. The smart contract may theninitiate the transfer of the token representing the reward to an accountof the user.

In embodiments, the user acquisition system 810 may perform theseservices for third-party customers. In these embodiments, a third-partycustomer may provide rewards (e.g., cash, cryptocurrency, gift cards,physical items, etc.) to a trusted third-party holder (e.g., thetokenization platform or another trusted holder). The rewards may thenbe tokenized and held in escrow. The third-party may further define theparameters governing the rewards (e.g., how much incentive to award, whomay be a promoter, etc.). The user acquisition system 810 may generate asmart contract on behalf of the third-party customer. When a userrequests a referral code, the user acquisition system 810 may generatean instance of the smart contract on behalf of the customer and mayassociate the instance of the smart contract with the account of theuser. When the user successfully refers a buyer to the customer using areferral code, the user acquisition system 810 (and/or the instance ofthe smart contract) may transfer a token representing the reward to anaccount of the referring user.

To further describe some embodiments in greater detail, reference isnext made to examples of techniques which may be performed by or inconnection with ecommerce systems, for example, platform 100. Thetechniques include technique 900 of FIG. 9, 1000 of FIG. 10, 1100 ofFIG. 11, 1200 of FIG. 12, 1300 of FIG. 13, 1400 of FIG. 14, 1500 of FIG.15, 1600 of FIG. 16, 1700 of FIG. 17, 1800 of FIG. 18, and 1900 of FIG.19. Technique 900, technique 1000, technique 1100, technique 1200,technique 1300, technique 1400, technique 1500, technique 1600,technique 1700, technique 1800, and technique 1900 can be executed usingcomputing devices, such as the systems, hardware, and software describedherein. Technique 900, technique 1000, technique 1100, technique 1200,technique 1300, technique 1400, technique 1500, technique 1600,technique 1700, technique 1800, and technique 1900 can be performed, forexample, by executing a machine-readable program or othercomputer-executable instructions, such as routines, instructions,programs, or other code. The steps, or operations, of technique 900,technique 1000, technique 1100, technique 1200, technique 1300,technique 1400, technique 1500, technique 1600, technique 1700,technique 1800, and technique 1900 or another technique, method,process, or algorithm described in connection with the embodimentsdisclosed herein, can be implemented directly in hardware, firmware,software executed by hardware, circuitry, or a combination thereof. Forsimplicity of explanation, 900, technique 1000, technique 1100,technique 1200, technique 1300, technique 1400, technique 1500,technique 1600, technique 1700, technique 1800, and/or technique 1900are each depicted and described herein as a series of steps oroperations. However, the steps or operations in accordance with thisdisclosure can occur in various orders and/or concurrently.Additionally, other steps or operations not presented and describedherein may be used. Furthermore, not all illustrated steps or operationsmay be required to implement a technique in accordance with thedisclosed subject matter.

FIG. 9 depicts a flowchart showing a technique 900 for tokenizing itemsaccording to some embodiments of the present disclosure. At 9002, iteminformation is obtained. The item information may include a uniqueidentifier for a unique unit of the item and a set of item attributes.In embodiments, a processing system of a tokenization platform obtainsthe information.

At 904, one or more digital tokens are generated. In embodiments, thedigital tokens are unique digital tokens. Each unique digital token mayinclude a set of digital attributes that correspond to the set of itemattributes. In embodiments, N digital tokens are generated and linked toan item or virtual representation thereof. In embodiments, a tokengeneration system generates the one or more digital tokens.

At 906, the digital token is coupled to the item information. Inembodiments, a cryptographic link couples the digital token to the iteminformation such that the digital token provides a representation of theitem. For example, the digital token and the item may be unique suchthat the unique digital token and the unique identifier for the uniqueunit of the item are cryptographically linked to provide a uniquedigital representation of the unique unit of the item. In embodiments, alinking system, such as a module of the token generation system 302,couples the digital token to the item information.

In embodiments, tokens may be tokenized (e.g., when generating a tokenrepresenting an amount of funds). For example, the item information maybe funds within the platform 100 or from third-party sources. Thetokenized token can be generated in response to validation of receipt ofthe funds, and the funds may be held from transaction by the user. Insome embodiments, the funds remain publicly attributed to the user andthe ledger is updated with a hold or lien recorded against the funds toprevent user transaction of the tokenized funds without approval by theplatform 100. In some embodiments, the ledger is updated to reflect atransfer of the funds from the user to the platform 100. Beneficially,transferred funds may be tradeable by the platform 100 (e.g., fordepositing or investment with third parties), and the tokenized tokensare redeemable for an equivalent amount of the original funds even ifthe redeemed funds are not the originally tokenized funds such that thetokenized token may be used by transactions within the platform 100while the deposited funds may participate in economic transactionsbetween the platform 100 and third parties.

FIG. 10 depicts a flowchart showing a technique 1000 for transferringtokens using a digital marketplace according to some embodiments of thepresent disclosure. At 1002, a ledger is maintained. The ledger stores aplurality of public addresses, a plurality of virtual representations ofa plurality of respective items, and, for each virtual representation, aset of tokens, and ownership data of each respective token. The set oftokens respectively correspond to a respective instance of the itemrepresented by the virtual representation. Further, each respectivepublic address corresponds to a respective account of a respective userof the tokenization platform.

At 1004, a digital marketplace is provided. In embodiments, the digitalmarketplace provides a graphical user interface that allows consumers toview visualizations of virtual representations of items including thevirtual representation of the item and transact for an instance of theitem by purchasing a digital token of the N digital tokens. Upon a userpurchasing a token, the ledger may be updated to reflect a change inownership of the token from the seller of the token to the user. Once auser owns a token, the user may be allowed to transfer the token toanother user, sell the token, use the token as collateral, and/or redeemthe token.

At 1006, a redemption is processed in response to a user requestingredemption of the token. In embodiments, the redemption may begin byassociating a specific token that corresponds to the virtualrepresentation with an account of the transacting user. The associationmay be made in response to verifying the request to participate in thetransaction. A transfer request is received requesting transfer of thespecific token to a transferee. The transfer request includes adigital-token identifier that identifies the specific token and a publicaddress of the different user. Further, the specific token is validated.The validation can be based on the digital-token identifier and theledger. In the process, the account of the transferee on the platform100 may be verified and/or validated based on the public address of theuser and the ledger. Additionally, the ledger is updated with a blockthat includes ownership data and indicates that a specific tokencorresponding to the virtual representation is owned by the transactinguser. In embodiments, the updating occurs in response to both validatingthe specific token and verifying the transferee. Yet further, aredemption request is received to redeem the digital token from a userdevice of the transferee, and a workflow is executed to satisfy thetransaction for instance of the item corresponding to the token. Theworkflow may be initiated in response to receiving the redemptionrequest.

FIG. 11 depicts a flowchart showing a technique 1100 for transferringtokens between wallets via a keyboard interaction according to someembodiments of the present disclosure. At 1102, one or more wallets aredisplayed. The display of the one or more wallets may include, forexample, displaying a digital wallet graphical user interface via a userdevice of a user associated with the digital wallet. Additionally, aninventory of tokens that are owned by the user may be displayed by thedigital wallet graphical user interface. In embodiments, each tokencorresponds to a respective item and may be redeemable by a user tosatisfy a transaction for an instance of the respective item.

At 1104, transfer instructions are received. The transfer instructionmay include indication of one or more digital tokens from the inventoryof tokens and a recipient of the digital token. The transferinstructions can be received by the digital wallet graphical userinterface.

At 1106, the digital tokens are transferred in response to keyboardinteractions. In embodiments, a digital keyboard is displayed by thedigital wallet graphical user interface. The digital keyboard includes aselectable media content that is representative of the itemcorresponding to the digital token within the transfer request. Userinput producing a text-based message including a selection of theselectable media content by the digital keyboard is received. Forexample, the user may type a message surrounding the transfer (e.g.,“Please enjoy this gift from me) and may then select the selectablemedia content representing the token (e.g., an image of the itemrepresented by the token) to create a message having the token embeddedtherein. The selectable media content includes the digital token/anidentifier of the digital token (e.g., a hash value that uniquelyidentifies the digital token). The digital token (e.g., an identifierthereof) is embedded within the text-based message by the digitalkeyboard, and the digital wallet transmits the text-based message to amessage account of the recipient. Upon receipt, the digital token isaccepted into a respective digital wallet of the recipient in responseto the recipient selecting the selectable media content.

FIG. 12 depicts a flowchart showing a technique 1200 for redeemingtokens according to some embodiments of the present disclosure. At 1202,ledger data is maintained. The ledger data can include a plurality ofpublic addresses, a plurality of virtual representations, a set oftokens for each of the plurality of virtual representations, andownership data for each of the set of tokens. Each respective publicaddress corresponds to a respective account of a respective user of thetokenization platform. The virtual representations correspond torespective items, and the set of tokens respectively correspond to arespective instance of the respective item for each virtualrepresentation.

At 1204, a redemption request is received. The redemption request seeksto redeem a digital token from a user device of a user, and the digitaltoken corresponds to an instance of the item to be redeemed. At 1206,ownership of the digital token by the user is verified. The verificationcan be made based on the plurality of public addresses, the sets ofdigital tokens, and the redemption request. For example, the redemptionrequest may include a user id of a user wishing to redeem a tokenindicated by a token identifier. The platform 100 may validate theownership of the token by checking that the ledger data links the tokenidentifier indicated in the redemption request to the public address ofthe user indicated in the redemption request. If so, the ownership ofthe digital token is verified.

At 1208, details for fulfilment and/or delivery are managed by theplatform 100. In some embodiments, the platform 100 may prompt the userto provide delivery details (e.g., via a graphical user interface). Inresponse, the platform 100 may receive the delivery details from theuser via the user device. The delivery details may then be output to adelivery system, which initiates delivery of the redeemed token. Forexample, the user may provide a physical address and any other relevantdelivery data (e.g., best time of day for delivery or phone number). Inthis case, the delivery system may use the provided address to initiatea delivery of the item represented by the redeemed token. In anotherexample, the token may represent a digital item. In such cases, the usermay provide an email address or other account data to which the digitalitem (or a link thereto) may be delivered. In some embodiments, theplatform 100 may request fulfilment details in response to verifyingthat the user is the owner of the token. The fulfilment details includeinformation needed to satisfy the transaction for the item that were notprovided at a time when the token was transacted for. For example, thefulfilment details may include item constituent materials, sizing,color, combinations thereof, and the like. The fulfilment details may bereceived from the user device of the user and outputted to a fulfilmentsystem. The fulfillment system may initiate delivery of an item thatsatisfies the fulfillment details.

FIG. 13 illustrates a flowchart showing a technique 1300 forcollateralization and/or securitization according to some embodiments ofthe present disclosure. At 1302, an item conversion request is received.In embodiments, the item is a tangible item. In other embodiments, theitem is other forms of collateral. At 1304, item information isreceived. The item information may include information that is requiredor helpful in determining valuation of the item. For example, the iteminformation may include one or more photographs of the item, adescription of the item, an appraisal value of the item, and/or aholding location of the item.

At 1306, a virtual representation of the collateral item is generatedbased on the item information. At 1308, one or more tokens are generatedbased on the virtual representation. At 1310, ownership of the digitaltoken is assigned. Initially, the ownership of the digital token isassigned to the owner of the collateralized item represented by thedigital token. At 1312, an agreement that is backed by the item ismemorialized. In embodiments, the item is an asset that is used ascollateral to an agreement to provide a service for the user by aprovider. In embodiments, an instance of a smart contract that governsthe service is generated. The smart contract indicates an amount to beprovided by the user to the provider and one or more conditions thatcause ownership of the digital token to be transferred to the provider.The instance of the smart contract may then be deployed by theprocessing system. In embodiments, the item is a collateralizable itemthat is used as loan security. The agreement to loan a defined amount offunds to the user by a lender is received by the processing system. Aninstance of a smart contract governing the loan is generated by theprocessing system. The instance of the smart contract indicates anamount to be paid back by the user to the lender, as well as one or moreconditions that cause ownership of the token to be transferred to thelender (e.g., default conditions). The instance of the smart contract isthen deployed by the processing system. In some embodiments, the tokenmay be placed in escrow, such that the lendee cannot redeem or transferthe token until the loan is paid. In these embodiments, the smartcontract may define conditions that result in the token beingtransferred back to the lendee (e.g., when payment is complete).

FIG. 14 illustrates a flowchart showing a technique 1400 for itemauthentication according to some embodiments of the present disclosure.At 1402, a tokenization request is received from a user device. At 1404,item information is received. In some embodiments, the item informationmay be provided by a user or via an automated process. At 1406, avirtual representation of the item is generated.

At 1408, the authenticity of the item is determined through suitableauthentication processes. In embodiments, an authentication of the itemmay be requested via a portal that is accessible by subject-matterauthentication experts. In these embodiments, the portal may furtherdisplay the virtual representation of the item. For example, thesubject-matter expert may be presented with an image of the item, adescription of the item (e.g., weight, dimensions, etc.), a video of theitem, and/or the like. An authentication report may then be received bythe processing system. The authentication report may be provided by asubject-matter authentication expert, which may include an opinionindicating whether the subject-matter authentication expert deemed theitem authentic or not-authentic and one or more reasons for the opinion.In some embodiments, the platform may generate a digital token inresponse to an opinion indicating that the item is deemed authentic, andownership of the digital token assigned to an owner of the item. Thedigital token may be based on a virtual representation of the item.

FIG. 15 depicts a flowchart showing a technique 1500 for rendering VRenvironments. Leger data is maintained at 1502 using suitable processessuch as those discussed above. At 1504, an environment is rendered. Inembodiments, a virtual reality store environment is rendered, whichprovides an interface that allows users to view virtual realityvisualizations of available items and to transact for instances of theavailable items. The available items are items which are available fortransaction. Further, a virtual reality visualization of an itemrepresented by a virtual representation may also be included within thevirtual reality store environment. At 1506, the item within the virtualenvironment is transacted through suitable processes. For example, arequest to participate in a transaction for an instance of the item isreceived by the platform 100 from a user device of a transacting user.In embodiments, the request to participate in the transaction isreceived in response to the transacting user viewing the virtual realityrepresentation of the item in the virtual reality store environment.Information associated with the request may be verified, and thespecific token corresponding to the virtual representation is associatedwith an account of the transacting user in response to verifying therequest to participate in the transaction.

FIG. 16 illustrates a flowchart showing a technique 1600 forfacilitating transactions using a distributed ledger with a side chainof blocks according to some embodiments of the present disclosure.

At 1602, a ledger is maintained. The ledger includes a main chain ofblocks and a side chain of blocks. In embodiments, blocks of the mainchain collectively store information relating to a plurality of users,which include both item providers and item consumers. The informationrelating to the plurality of users includes a plurality of publicaddresses, and each respective public address corresponds to arespective account of a respective user of the tokenization platform.Blocks of the side chain collectively store a plurality of virtualrepresentations of a plurality of respective items, a set of tokens foreach virtual representation, and ownership data of each respectivetoken. Each virtual representation includes virtual reality content torender a virtual reality visualization of the respective item, and eachset of tokens respectively corresponds to a respective instance of theitem represented by the virtual representation.

At 1604, a transaction request is received through a suitable process,such as those described above. At 1606, transaction of the item occurs.In embodiments, ownership data of a specific token corresponding to thevirtual representation in the first side chain of blocks is updated toindicate that the transacting user owns the specific token. Inembodiments, the transaction of the item includes validating thespecific token based on the digital-token identifier and the first chainof blocks, verifying that the different user has a valid account on thetokenization platform based on the public address of the user and themain chain of blocks, and, in response to validating the specific tokenand verifying the different user, updating the second chain of blockswith a new block. The new block includes ownership data that indicatesthat the specific token corresponding to the virtual representation isowned by the different user.

FIG. 17 depicts a flowchart showing a technique 1700 for facilitatinguser acquisition according to some embodiments of the presentdisclosure. At 1702, a referral code is generated, which corresponds toa user of the tokenization platform. The referral code may be generatedby a processing system of the tokenization platform. At 1704, aninstance of a smart contract is generated that corresponds to the userof the tokenization platform. The instance of the smart contract may begenerated by the tokenization platform. The instance of the smartcontract indicates an incentive to be provided to the user when the usersuccessfully refers the tokenization platform. At 1706, the instance ofthe smart contract is deployed by the processing system. At 1708, arequest to create a new account is received from a new user by theprocessing system. The request includes the referral code of the user.At 1710, the new account is created for the new user by the processingsystem. At 1712, the processing system provides a notification of thenew account to the instance of the smart contract corresponding to theuser. The smart contract then facilitates the transfer of a tokenrepresenting the incentive in response to the notification.

FIG. 18 depicts a flowchart showing a technique 1800 for managingmystery boxes according to some embodiments of the present disclosure.At 1802, a request to create a mystery box is received by the processingsystem. At 1804, a set of tokens to be included in the mystery box isreceived by the processing system. Each token in the set of tokensrepresents a respective item and has a probability assigned thereto. Theprobability indicates a probability of winning the respective item.

At 1806, the mystery box is generated by the processing system based onthe set of tokens and the probabilities assigned thereto. Each token inthe set of tokens is assigned a range of values within an interval ofvalues such that the range of values with respect to the interval ofvalues is proportionate to the probability assigned to the token.

At 1808, an instance of a smart contract is generated by the processingsystem. The smart contract is associated with the mystery box andgoverns the transfer of tokens from the set of tokens in support of themystery box. At 1810, the instance of the smart contract is deployed bythe processing system.

FIG. 19 depicts a flowchart showing a technique 1900 for video-gameintegration according to some embodiments of the present disclosure. At1902, an inventory of available tokens is maintained. The availabletokens are available for integration in a video game. Each token in theinventory of tokens represents a respective item. At 1904, a tokenrequest for a digital token is received by the processing system. Thedigital token is from an instance of the video game via an API. At 1906,the processing system selects the digital token from the inventory ofavailable tokens based on the token request. At 1908, an indicator ofthe token is provided to the instance of the video game by theprocessing system. At 1910, the processing system receives a transactionrequest from the instance of the video game. The transaction request isconfigured to request a transfer of the token provided to the instanceof the video game to an account of a user of the instance of the videogame. At 1912, the ledger is updated to reflect that the user is theowner of the token.

FIG. 20 illustrates an example ecosystem 2000 for facilitatingsecuritized decentralized loan processes (also referred to as a“decentralized loan process”, “securitized loan process”, or “loanprocess”). A securitized decentralized loan process may refer to aprocess that is distributed amongst a series of participants (e.g.,vis-à-vis computing systems 100, 2014 and devices 2002, 2004, 2006,2008, 2010) and a set of smart contracts hosted on the set ofdistributed ledgers 2016, such that a borrower can collateralize one ormore physical items in a trustless or substantially trustless manner anda lender is empowered to loan money to the borrower in a trustless orsubstantially trustless manner (e.g., without having to personallyauthenticate, appraise, safekeep, and/or liquidate the collateral item).In particular, the disclosed ecosystem and the systems and methods thatsupport it provide mechanisms that allow a borrower to digitallycollateralize a physical item into a digital collateral token 2042, suchthat the digital collateral token 2042 can be used to secure a loan froma lender using smart contracts. In embodiments, the stages of adecentralized loan process may include one or more of: a request stagewhere a borrower requests to being a loan process; an authenticationstage where a collateral item is authenticated by one or moreauthenticators; an appraisal stage where the collateral item isappraised by one or more appraisers; a safekeeping stage where thecollateral item is deposited with a safekeeper until an instance of theloan process ends; a virtualization stage where a VIRL corresponding tothe collateral item is generated; a tokenization stage where the VIRL istokenized into a collateral token 2042; a loan request stage where aborrower may request a loan and/or negotiate the terms of the loan withone or more potential lenders that ends with the borrower and lenderagreeing to the terms of the deal and the locking of the collateraltoken into an escrow account until the loan process is completed; a loanrepayment stage where the loan is repaid by the borrower or defaultedon; and a post-loan stage where the collateral token 2042 is transferredback to the borrower if the loan is successfully repaid or liquidated toa buyer if the borrower has defaulted, the collateral token is redeemedfor the collateral item from the safekeeper, and/or any post-loananalytics are performed.

In some example embodiments, a tokenization platform 100 supportssecuritized decentralized loan processes. In these example embodiments,a marketplace system 102, a ledger management system 104, a collateralmanagement system 802, an authentication system 804, and an analyticsand reporting system 112 may be configured to interface with a set ofuser devices (e.g., borrower devices 2002, authenticator devices 2004,appraiser devices 2006, safekeeper devices 2008, and/or lender devices2010) in facilitating the decentralized loan processes vis-à-vis a setof distributed ledgers 2016 hosted by a set of node devices 2014. Inembodiments, the securitized decentralized loan ecosystem 2000 includesa number of different participants that participate in different stagesof a securitization decentralized loan process. In some embodiments, theparticipants in the loan may include borrowers that seek to obtain aloan using physical collateral items, authenticators that authenticatethe physical collateral items, appraisers that appraise the physicalcollateral items, safekeepers that safely store the physical collateralitems, lenders that lend currency to the borrowers, as well as othersuitable participants that support a distributed ledger ecosystem (e.g.,“miners” and/or distributed ledger node devices 2014). As will bediscussed, some types of participants may be organized into guilds,which are groups of entities (e.g., individuals and/or businesses) thathave subject-matter expertise that pertains to a particular stage, suchas authentication, appraisal, and safekeeping. It is appreciated thatthe participants in the securitized decentralized ecosystem 2000 mayinteract with one another and with the distributed ledger(s) 2106 viavarious computing devices, such as laptop computers, desktop computers,tablets, video game consoles, server computers, and/or the like. Forpurposes of explanation, a borrower participates in the ecosystem 2000via a borrower device 2002, an authenticator participates in theecosystem 2000 via an authenticator device 2004, an appraiserparticipates in the ecosystem 2000 via an appraiser device 2006, asafekeeper participates in the ecosystem 2000 via a safekeeper device2008, a lender participates in the ecosystem 2000 via a lender device2010, and the like.

In embodiments, a securitized decentralized loan process may be at leastpartially implemented using a set of distributed ledgers 2016 hosted bya network of node devices 2014, where the node devices 2014 executesmart contracts instances that are created in connection with asecuritized loan process, including one or more smart contracts thatmanage the authentication, appraisal, and/or securitization of one ormore collateral items. In some embodiments, one or more stages in thedecentralized loan process are managed by a respective set of smartcontracts. In general, a smart contract may include computer executablecode that, when executed, executes conditional logic that triggers oneor more actions. Smart contracts may receive data from one or more datasources, whereby the conditional logic analyzes the data to determine ifcertain conditions are met, and if so, triggers one or more respectiveactions. Examples of smart contracts are discussed throughout thedisclosure, including examples of conditional logic and triggeringactions. In embodiments, the smart contracts may be defined inaccordance with one or more protocols, such as the Ethereum protocol,the WAX protocol, and the like. Smart contracts may be embodied ascomputer-executable code and may be written in any suitable programminglanguages, such as Solidity, Golang, Java™, JavaScript™, C++, or thelike. Various examples of smart contracts that may be used in connectionwith various embodiments of the securitized decentralized are discussedthroughout the disclosure. In example embodiments of FIG. 20, adistributed ledger 2016 may store and the node devices 2014 may executeinstances of: loan process smart contracts 2022, stage-level governancesmart contracts 2024, guild governance smart contracts 2026,authentication smart contracts 2028, appraisal smart contracts 2030,safekeeping smart contracts 2032, loan smart contracts 2034, and/orother suitable smart contracts. The different types of smart contractsare discussed throughout the disclosure.

In embodiments, the distributed ledgers 2016 may store tokens that areused in connection with a decentralized loan process, including, but notlimited to, collateral tokens 2042 that are generated in connection withthe decentralized loan process and held as collateral to secure a loan,guild tokens 2044 that are owned and/or used by guild members (which canbe used by guild members to vote, as discussed below) that perform acertain task in connection with a decentralized loan process,currency/tokenized tokens 2046 that are utilized in connection with thedecentralized loan process (e.g., for lending, for repayment, forrewarding, for staking, or the like), and other suitable tokens. Inembodiments, a collateral token 2042 may be a digital token that wrapsone or more virtual representations of a physical item (VIRLs) of one ormore respective collateral items that are used to securitize a loan in adecentralized loan process. In embodiments, the VIRL corresponds to aphysical item and may include descriptions of the item, photographs ofthe item, videos of the item, and the like. Virtual representations(VIRLs) of physical items are discussed throughout the disclosure. Inembodiments, a collateral token 2042 may include a smart contractwrapper, such that when an owner of the collateral token (as determinedfrom an ownership record of the collateral token after a loan has beenrepaid and/or after a liquidation event) redeems the token (as discussedabove), the smart contract associated with the collateral token 2042 mayprovide a notification to the safekeeper of a collateral itemrepresented by the collateral token 2042 to provide the collateral item.Once the safekeeper confirms that the holder of the collateral token2042 has taken possession of the collateral item, the smart contract ofthe collateral token 2042 may burn the redeemed collateral token 2042,as described above. Currency tokens may refer to digital tokens that areused as currency. Examples of currency tokens may include Bitcointokens, Ethereum tokens, Ripple tokens, Wax tokens, and the like. Insome embodiments, a tokenized token refers to a digital token that“wraps” an amount of currency (e.g., a currency token and/or fiatcurrency). When a tokenized token is created, an amount of currency isheld escrow and the tokenized token represents an ownership right to theescrowed amount of currency, such that when the tokenized token isredeemed by a verified owner of the tokenized token, the owner may takepossession of the escrowed amount of currency. As currency tokens andtokenized tokens are both representative of currency, use of the term“currency/tokenized” tokens may refer to either currency tokens,tokenized tokens, or a combination of both currency tokens and tokenizedtokens.

In embodiments, the distributed ledgers 2016 may store additional data,such as event records 2052, ownership data 2054, and/or supporting data2056. Event records 2052 may include records that memorialize any eventsthat occur in connection with a decentralized loan process. Eventrecords 2052 may include records of events such as, but not limited to:a request by a borrower to being a loan process, an authentication taskbeing assigned, an authentication task being completed, an appraisaltask being assigned, an appraisal task being completed, a safekeepingtask being assigned, a safekeeping task being completed, a loan beingrequested by a borrower, a loan being accepted by a lender, a locking ofa collateral token of a borrower that is locked in escrow in response toa loan agreement being entered into by the borrower, a payment beingmade by the borrower to the lender, a payment being missed by theborrower, the transfer of a loan contract to a secondary lender from acurrent lender, a loan being determined to be in default by a borrower,a liquidation event occurring, a loan being fully repaid by theborrower; rewards being awarded to participants in a decentralizedprocess, an item being deemed fake after a liquidation event, an itemfailing to reach an appraised value during a liquidation event, and thelike. In embodiments, an event record may be generated by any suitablecomputing device within the ecosystem 2000, such as the tokenizationplatform 100, borrower devices 2002, authenticator devices 2004,appraiser devices 2006, safekeeper devices 2008, lender devices 2010,node devices 2014 (e.g., by smart contracts executed by the node devices2014), or other suitable devices. In embodiments, an event record 2052may be hashed using a hashing function to obtain a hash value. The eventrecord 2052 may be written into a data block and stored in a distributedledger, where the data block may include the hash value. In this way,the data within the event record 2052 cannot be changed without changingthe hash value of the event record 2052, thereby making the event record2052 immutable. Once a block containing an event record 2052 is storedon a distributed ledger, the event record 2052 may be referenced usingan address of the block with respect to the distributed ledger 2016.

In embodiments, supporting data 2056 may be documentation and data thatis provided in support of a task performed or other events that occur inconnection with decentralized loan processes and/or the participants ofthe decentralized loan processes. As will be discussed, supporting data2056 may include authentication reports and supporting photographs,videos, scans or the like; appraisal reports and supporting photographs,videos, scans or the like; safekeeping reports and supportingphotographs, videos, scans or the like; loan negotiation records thatindicate negotiation events during negotiation of a loan contract;disbursement records that correspond to disbursement events by a lenderto the borrower; repayment records that indicate payment events by thelender; default records that indicate default events; and/or othersuitable data.

In embodiments, ownership data 2054 may include data that associates atoken (e.g., collateral tokens 2042, currency/tokenized tokens 2046,and/or guild tokens 2044) to an account. In embodiments, ownership data2054 may be stored in data blocks, where a data block may include a linkbetween a token address and an account address. For example, if Bob owns10 currency tokens (e.g., bit coins), the ownership data 2054 of eachtoken may be stored on a distributed ledger and may link the respectivetokens to an account associated with Bob. If Bob uses one of thosetokens 2046 to purchase an item from Alice, the ownership data 2054 ofthe token can be updated to link the token 2046 used to purchase theitem to an account of Alice. When ownership changes to a new account, anew block may be amended to the distributed ledger 2016 that links thetoken with the new account. In embodiments, tokens (e.g., collateraltokens 2042 and/or currency/tokenized tokens 2046) may be locked duringthe course of a loan process. As used herein, “locking” a token mayrefer to storing the token in an escrow account (e.g., on a distributedledger that stores escrowed tokens), whereby a locked token cannot betransferred from the escrow account unless a smart contract associatedwith the token determines that the token has been unlocked. Inembodiments, a collateral token may be “locked,” for example, upon aborrower and lender agreeing to loan terms. In some embodiments, acertain amount of currency/tokenized tokens 2046 belonging toparticipants (e.g., authenticators, appraisers, and/or safekeepers) maybe locked when the participants perform certain tasks in relation tosecuring a loan (e.g., authentication tasks, appraisal tasks, andsafekeeping tasks) to provide an incentive to the participants toparticipate in the loan process in good faith (e.g., err on the side ofnot authenticating a collateral item, not overvalue collateral items toincrease rewards for appraising, and to store collateral itemsproperty). When a token is “locked,” ownership data 2054 that links thetoken to an escrow account that is managed by a trusted third party(e.g., the tokenization platform 100) may be added to the distributedledger. Once locked in the escrow account, the token cannot be redeemedor transferred unless it is unlocked. Once an event that triggers achange in ownership of a token (e.g., repayment of at least a portion ofthe loan) occurs, the ownership data 2054 of the token may be updated inthe distributed ledger 2016 storing the ownership data 2054 to reflectthat the token is owned by the rightful owner (e.g., the borrower, aparticipant, a buyer of the token, or the like), thereby unlocking thetoken. In some embodiments, when a collateral token 2054 is locked, theowner of the physical item may be precluded from using the virtualrepresentation of the item in a virtual environment. For example, if theowner of a physical item that is tied to a video game via a VIRL (e.g.,the owner of a shoes also owns a VIRL of the shoes that when used in thevideo game give the owner special features in the video game, such asrunning faster or jumping higher) collateralizes the physical item usingthe techniques described herein and locks the resultant collateral token2042 in an escrow account, the locking of the collateral token willresult in the user being precluded from using the VIRL of the physicalitem in the video game. In embodiments, an external virtual environment,such as a marketplace, a video game, a social media platform or the likemay be configured to query a distributed ledger to obtain the ownershipdata 2054 of a VIRL. If the VIRL is wrapped in a collateral token 2042that is held in escrow, the virtual environment may determine that thecorresponding collateral token is held in escrow and may preclude a userfrom using the VIRL in the virtual environment until the ownership data2054 of the VIRL indicates that the user owns the VIRL.

It is noted that in addition distributed ledgers 2016, event records2052, ownership data 2054, and supporting data 2056 and other suitabledata that supports the decentralized loan processes may be stored innon-distributed datastores, filesystems, databases, and the like. Forexample, in embodiments, the tokenization platform 100 may maintain datastores that store event records 2052, ownership data 2054, andsupporting data 2056 and other suitable data that supports thedecentralized loan processes.

In embodiments, certain groups of participants (e.g., authenticators,appraisers, safekeepers, and the like) in the decentralized loan processmay form or be organized into guilds based on a common expertise in anarea in accordance with a set of governances that are defined tofacilitate a securitized decentralized loan process. In general, guildformation, membership, and operations thereof, as well as thetransactions (and other events) performed during a loan process andmechanisms for facilitating a loan process adhere to a set ofgovernances. Governances may refer to respective sets of rules and/orregulations to which one or more aspects of the loan process and theparticipants adhere. In embodiments, governance may be defined in a setof files and/or documents (e.g., governance documents) that are storedon a distributed ledger and/or a centralized computing system (e.g., thetokenization platform). In some embodiments, governance may be enforcedby the use of smart contracts and/or software applications that areexecuted by a centralized computing system (e.g., the tokenizationplatform 100). In embodiments, the set of governances may include asystem-level governance that applies to the entire loan process (e.g.,all transactions and participants that participate in the loan process),stage-level governances that apply to participants that participate in aparticular stage (or set of stages) of the loan process and thetransactions that are performed during the particular stage (or set ofstages), guild-level governances that apply to respective guilds thatparticipate in a respective stage and/or the transactions in which theguild members participate, and/or sub-guild governances that apply torespective sub-guilds formed from respective guilds and the transactionsin which the sub-guild members participate. In embodiments, the set ofgovernances are hierarchical, whereby the system-level governance takesprecedent over stage-level governances that correspond to respectivestages of the loan process, a stage-level governance of a respectivestage takes precedent over guild-level governances of respective guildsthat participate in the respective stage, and a guild-level governanceof a respective guild takes precedent over sub-guild governances ofsub-guilds formed from within the respective guild. Put another way, asub-guild governance of a sub-guild can expand on or further refine, butnot contradict, the rules and regulations put forth in the guild-levelgovernance of the guild from which the sub-guild was formed; aguild-level governance can expand on or further refine, but notcontradict, the rules and regulations put forth in the stage-levelgovernance of the stage in which the guild participates, and astage-level governance can expand on or further refine, but notcontradict, the rules and regulations put forth in the system-levelgovernance. It is appreciated that none of the different types ofgovernances are required and certain stages and guilds may adhere to ahigher-level of governance (e.g., the system-level governance or astage-level governance) without departing from the scope of thedisclosure.

As discussed, the term “guild” may refer to a set of entities (e.g.,individuals or companies) that perform a defined type of specializedtask (e.g., authentication, appraisal, and/or safekeeping of specifictypes of collateral items) that may be domain specific (e.g.,authentication of watches, appraisal of sneakers, safekeeping ofvaluable and/or perishable items), whereby members of the guild adhereto a set of governances. For purposes of explanation, guild members aredescribed as individuals, but it is appreciated that organizations maybe comprised of individuals that have the same areas of expertise andtherefore may be included in guilds. In some embodiments, a guild mustadhere to the system-level governance, a stage-level governancecorresponding to the stage in which the guild participates, and/or aguild-level governance of the guild to which the guild member belongs.The stage-level governance may define the rules and regulations thatpertain to all participants that can participate in a stage (e.g.,authentication stage, appraisal stage, safekeeping stage, lending stage,and the like). For example, an authentication stage-level governance mayapply to any authenticators that perform authentication tasks inconnection in a decentralized loan process, an appraisal stagegovernance may apply to any appraisers that perform appraisal tasks inconnection with a decentralized loan process, a safekeeping stagegovernance may apply to any safekeepers that perform safekeeping tasksin connection with a decentralized loan process, a lending stagegovernance may apply to any lenders that lend money with a decentralizedloan process, and the like. Guild-level governances may define rules andregulations to members of a particular guild that participate in aparticular stage. For example, a watch authentication guild governancemay only pertain to members of a watch authentication guild, a handbagauthentication guild governance may only pertain to members of a handbagauthentication guild, a jewelry authentication guild governance may onlypertain to members of a jewelry authentication guild, a watch appraisalguild governance may only pertain to members of a watch appraisal guild,a handbag appraisal guild governance may only pertain to members of ahandbag appraisal guild, a sneaker appraisal guild governance may onlypertain to members of a sneakers appraisal guild, and the like. Inembodiments, a stage-level guild governance may define one or more of:the manner by which guilds can be created, the manner by which guildmembers are added to a guild; the manner by a guild member is removedfrom the guild, the manner by which guild members vote on amending thegovernance, workflows, smart contracts, and/or documents that areimplicated by certain tasks that are performed by a respective guild(e.g., appraisals, authentications, safekeeping, and the like); votingmechanics; and the like. As discussed, the sets of governances may behierarchical in nature, such that lower-level governances are requiredto adhere and/or not contradict higher level governances. For instance,the authentication stage-level governance may define a set of rules andregulations that applies to all authenticators and a guild-levelgovernance may define a set of rules, recommendations, and/or regulationthat applies to a respective guild (e.g., a watch authentication guildor a jewelry authentication guild) within the broader group ofauthenticators (e.g., all authenticators). In this example, theguild-level governance may be required to adhere and not contradict tothe stage-level governance, but may refine rules and/or regulations inthe stage-level governance as well as add new rules and/or regulationsthat were not defined in the stage-level governance. For instance, anexample authentication stage-level governance may require thatauthenticators temporarily stake at least certain amount of funds (e.g.,half of a loan amount) for each authentication task performed by a guildmember. In this example, a guild-level governance of an authenticationguild (e.g., watch authentication guild) must require its guild membersat least stake the amount of funds defined in the authenticationstage-level governance in connection with authentication tasks performedby guild members, but the guild-level governance may require a greateramount (e.g., the entire loan amount) than the amount defined in theauthentication stage-level governance. In another example, an appraisalstage-level governance may require that appraisers provide documentarysupport for an appraisal and a guild-level appraisers governance thatpertains to a specific guild of appraisers may further refine whatdocumentary support is to be provided in support of an appraisalperformed by a guild member. Additional examples of governance rules,recommendations, and/or regulations are provided throughout thedisclosure.

In some embodiments, membership to a guild is at least in part decidedby existing guild members in accordance with the stage-level and/orguild-level governance of the guild. For example, in exampleembodiments, the stage-level governance and/or a guild-level governanceof a guild may provide that a guild member may nominate an individualnot in the guild to be added to the guild and the members of the guildmay vote to admit or deny the entity to the guild and may furtherinclude the mechanics on how to nominate, vote on, and admit a newmember to the guild. Thus, in order to add a new member to the guild,the existing guild members must conduct the nomination and votingprocess in accordance with the controlling governances. In someembodiments, voting may be managed using a guild governance smartcontract 2026. A guild governance smart contract 2026 may refer to asmart contract that is configured to manage administrative tasks of aguild, such as voting on amending a guild-level governance and/orstage-level governance (if the guild governance smart contract 2026pertains to the broadest guild), voting on adding new members to aguild, voting on removing members from a guild, issuing guild tokens2044 to guild members, and/or the like. In some of these embodiments, aguild governance smart contract 2026 that is used to vote in new membersinto a guild may include conditional logic that receives a nomination ofa potential guild member and determines whether certain conditions aremet (e.g., does the nominator have a high enough rating to nominate, hasthe nominator been a guild member long enough to nominate, does thenominator have a minimum number of guild tokens 2044 or other analogousstatus indicators to nominate a new guild member, was the properprotocol used, and/or the like). In response to verifying that thenomination is valid, the guild governance smart contract 2026 mayexecute an action that solicits votes from the current guild members andto tally the votes. Once a member is voted on, the guild governancesmart contract 2026 may be configured to determine whether the nomineehas received enough votes to be admitted to the guild. If so, thenominee is added to the guild. If not, the nominee is denied admittanceto the guild. In doing so, the guild governance smart contract 2026 maycreate one or more event records 2052 identifying the results of thevote and/or whether a new member was added to the guild. In embodiments,the event records 2052 may be written to a distributed ledger 2016. Theguild governance contract 2026 may perform additional actions, such asgranting the new member guild tokens 2044, creating a profile for thenew guild member, adding the new guild member to a roster from whichguild members are selected to perform tasks, and/or the like. Guildmembers may be added to a guild in other manners without departing fromthe scope of the disclosure.

In embodiments, an authentication guild may include a set of individualsor organizations that have domain specific expertise authenticating aparticular type (or types) of item(s). For example, a watchauthentication guild may be comprised of individuals that have expertiseauthenticating watches, a shoe authentication guild may be comprised ofindividuals that have expertise authenticating shoes, a handbagauthentication guild may be comprised of individuals that have expertiseauthenticating handbags, an art authentication guild may be comprised ofindividuals that have expertise authenticating works of art, a sportsmemorabilia guild may be comprised of individuals that have expertiseauthenticating sports memorabilia, a toy authentication guild may becomprised of individuals that have expertise authenticating collectibletoys, a jewelry authentication guild may be comprised of individualsthat have expertise authenticating jewelry, a clothing authenticationguild may be comprised of individuals that have expertise authenticatingdesigner clothing, an instrument authentication guild may be comprisedof individuals that have expertise authenticating musical instruments, arecord authentication guild may be comprised of individuals that haveexpertise authenticating rare or collectible records, a wineauthentication guild may be comprised of individuals that have expertiseauthenticating bottles of wine, a whiskey authentication guild may becomprised of individuals that have expertise authenticating bottles ofwhiskey, an automobile authentication guild may be comprised ofindividuals that have expertise authenticating limited editionautomobiles, and any other suitable authentication guild.

In embodiments, an appraisal guild may include a set of individuals ororganizations that have domain specific expertise appraising aparticular type (or types) of item(s). For example, a watch appraisalguild may be comprised of individuals that have expertise appraisingwatches, a shoes appraisal guild may be comprised of individuals thathave expertise appraising shoes, a handbag appraisal guild may becomprised of individuals that have expertise appraising handbags, an artappraisal guild may be comprised of individuals that have expertiseappraising works of art, a sports memorabilia appraisal guild may becomprised of individuals that have expertise appraising sportsmemorabilia, a toy appraisal guild may be comprised of individuals thathave expertise appraising collectible toys, a jewelry appraisal guildmay be comprised of individuals that have expertise appraising jewelry,a clothing appraisal guild may be comprised of individuals that haveexpertise appraising designer clothing, an instrument appraisal guildmay be comprised of individuals that have expertise appraising musicalinstruments and equipment, a record appraisal guild may be comprised ofindividuals that have expertise appraising rare or collectible records,a wine appraisal guild may be comprised of individuals that haveexpertise appraising bottles of wine, a whiskey appraisal guild may becomprised of individuals that have expertise appraising bottles ofwhiskey, an automobile appraisal guild may be comprised of individualsthat have expertise appraising limited edition automobiles, and anyother suitable appraisal guild.

Within some guilds there may be different classes of items that are muchmore popular than others and/or may require additional expertise. Forexample, within the watch authentication guild, there may be a largenumber of authentication requests to authenticate Rolex® watches someguilds, both because of the number of such watches on the market and thenumber of counterfeit watches that are meant to pose as Rolex® watches.Thus, in some embodiments, some stage-level governances and/orguild-level governances may provide a mechanism by which one or moresub-guilds can be formed, where a sub-guild of a guild is comprised ofindividuals of the guild that have expertise in authenticating aparticular subdomain of the guild's area of expertise. For example,within the watch guild, there may be respective sub-guilds thatspecialize in authenticating different brands of watches, such as Rolex®watches, Omega® watches, Hamilton® watches, and the like. In anotherexample, the shoe authentication guild, there may be respectivesub-guilds that specialize in authenticating different types of shoes,such as sneakers, high-tops, skateboarding shoes, heels, dress shoes orthe like, and/or sub-guilds that specialize in authenticating differentbrands of shoes, such as Nike® shoes, Jordan® shoes, Adidas® shoes,Gucci® shoes, Louboutin® shoes, or the like. In another example, withinthe art authentication guild, there may be respective sub-guilds thatspecialize in authenticating works of art in different mediums, such aspaintings, oil paintings, sculptures, lithographs, concert posters,swords, vases, pottery, and the like; different styles of art, such asimpressionist paintings, abstract paintings, post-modern art, pop art,graffiti, Japanese swords, Chinese vases, Faberge eggs, or the like;and/or art by different artists. As can be appreciated, different guildsmay be broken down into sub-guilds in different manners. Furthermore,because a sub-guild exists for a subdomain of the guild, does not meanthat all items must fall within a sub-guild. For example, if the watchauthentication guild includes a Rolex sub-guild but no other sub-guilds,a Rolex® watch may be authenticated by one or more authenticators in theRolex® sub-guild, but an Omega® watch may be authenticated by one ormore authenticators within the broader watch authentication guild,including members of the Rolex sub-guild.

In embodiments, the ability to form a sub-guild from within a respectiveguild may be defined in the respective guild's guild-level governanceand/or stage level governance. In some of these embodiments, formationof new sub-guilds from a respective guild may be managed and enforcedusing a guild governance smart contract 2026 corresponding to therespective guild. In some embodiments, a guild governance smart contract2026 may define the mechanics by which a sub-guild can be requested(e.g., automatically or by a set of guild members) and created. Forexample, a guild governance smart contract 2026 that is used by aparticular authentication guild (e.g., watch authentication guild) mayinclude conditional logic that defines a minimum number and/or minimumpercentage of guild members (e.g., watch authenticators) that arerequired to request/approve the creation a new sub-guild (e.g., a Rolexsub-guild). In this example, the guild-level governance of theparticular authentication guild may require that at least ten guildmembers and/or that at least 50% of the guild members voting power(where voting power may be determined using a voting token scheme wheremembers with more guild tokens 2044 have more voting power or a“one-member-one-vote” scheme where every member has one equally weightedvote) agree to the creation of a sub-guild. Additionally oralternatively, the guild governance smart contract 2026 may includeconditional logic that requires a minimum number or minimum percentageof verified successful authentication events (or other tasks if anotherstage) performed by the guild members involving a particular subclass ofitems to authorize the creation of a new sub-guild. For example, theguild governance smart contract 2026 of a shoe authentication guild mayrequire proof of at least one thousand successful authentication eventsand at least 5% of the total authentication events to involve aparticular class of shoes, and the shoe authentication guild hascollectively performed 10,000 successful authentication events involvinga pair of shoes, and over 1000 of those authentication events haveinvolved Nike® sneakers, the shoe guild may vote to create a Nike®sub-guild (or a “sneaker” sub-guild). In this example, the shoeauthentication guild's guild governance smart contract may requireanalytics to prove the over 1000 successful authentication events (whichmay include successful identification of knock-off sneakers and/orsuccessful authentication of authentic Nike® sneakers). In embodiments,the analytics to prove that the guild has reached the requisite numberof successful authentications may be obtained based on an analysis of adistributed ledger that stores authentication records. Furthermore, theshoe authentication guild-level governance may then require the guildmembers to vote on the creation of the new Nike® sub-guild, where thevoting scheme is defined in the shoe guild-level governance and/or theauthentication stage-level governance. Assuming all of the conditions tocreate a new sub-guild within the shoe guild are met, a guild governancesmart contract may trigger a “create new sub-guild” action. Inembodiments, the create new sub-guild action may include the creation ofa new governance that corresponds to the sub-guild that defines therules for the particular sub-guild, including rules for membership intothe sub-guild, compensation and commissions for the sub-guild, mechanicsfor verifying items that are classified in the sub-guild, how thesub-guilds secures the authentication event, authentication forms usedby the subgroup, and the like. It is noted that in embodiments, thesub-guild governance of the sub-guild may initially inherit one or moreaspects of the broader guild governance (some of which are changeable bythe sub-guild and some of which may not be changed by the sub-guild). Inembodiments, the “create new sub-guild” action may include issuing anotification of the new sub-guild to the tokenization platform 100, suchthat the platform 100 may update the assignment of authentication tasksinvolving items that are classified under the expertise of the newsub-guild to the new sub-guild.

FIG. 21 illustrates an example of guilds within a decentralized loanecosystem 2000 and the different types of governances that may governthe guild members and/or different aspects of the loan system. In theillustrated example, the stage-level guilds may include anauthentication guild 2102 comprised of authenticators that performauthentication tasks, an appraisal guild 2104 comprised of appraisersthat perform appraisal tasks, and a safekeeper guild 2106 comprised ofsafekeepers that perform safekeeping tasks. It is appreciated thatadditional or alternative types of participants may form guilds indifferent examples. For example, lenders may form a lenders guild (notshown). As discussed, within the authentication guilds, there may beguilds that include members having certain authentication specialties orthat are located in certain regions. In the illustrated example, withinthe authentication guild, there may be a watch authentication guild2112-1, a shoe authentication guild 2112-2, and/or any other suitableauthentication guilds (e.g., Nth authentication guild 2112-N). Withinsome of the authentication guilds, authentication sub-guilds may beformed. For example, within the watch guild 2112-1, a Rolex sub-guildmay be formed, where the members of the Rolex sub-guild 2122 may bewatch guild members that have a special expertise in authenticatingRolex® watches. In this way, members of the Rolex sub-guild 2112-1 willbe assigned authentication tasks pertaining to Rolex® watches (andpotentially of other types of watches), while watch guild 2112-1 membersthat are not in the sub-guild 2122 cannot authenticate Rolex® watchesbut can authenticate any other type of watch (assuming no other watchsub-guilds exist). Similarly, within the shoe authentication guild2112-2, a sneaker authentication sub-guild 2124-1 and a Gucciauthentication sub-guild 2124-1 have formed by members of the shoeauthentication guild 2112-2. In this example, members of the sneakerauthentication sub-guild 2124-1 can authenticate any type of sneakers,but shoe authenticators that are not in the sneaker authenticationsub-guild 2124-1 cannot authenticate sneakers. Similarly, members of theGucci authentication sub-guild 2124-2 can authenticate Gucci® shoes, butshoe authenticators that are not in the Gucci authentication sub-guild2124-2 cannot authenticate Gucci® shoes.

Within the appraisal guild 2104, there may be guilds that are directedto members having certain appraisal specialties or that are located incertain regions. In the illustrated example, within the appraisal guild2104 there may be a watch appraisal guild 2114-1, a shoe appraisal guild2114-2, and/or any other suitable appraisal guilds (e.g., Nth appraisalguild 2114-3). In the illustrated example, a Rolex appraisal sub-guild2126 has been formed from the watch appraisal guild 2114-1 and a Nikeappraisal guild 2128 has been formed from the shoe appraisal guild2114-2. As can be appreciated, the sub-guilds that are formed fromwithin the various guilds do not need to be congruent with sub-guildsthat are formed from guilds that participate in different stages. Forexample, while Rolex authenticators and Rolex appraisers formedrespective sub-guilds 2122, 2126, there is no counterpart Nikeauthentication sub-guild and no counterpart sneaker appraisal sub-guildor Gucci appraisal sub-guild formed. The manner by which sub-guilds areformed may be defined in the stage-level governance and/or the guildgovernance of the guild from which a sub-guild is to be formed.

In this example, there are no guilds formed out of the safekeeper guild2106. While this is the case in the current example, in some scenariosthere may be guilds that include safekeepers having certain safekeepingspecialties or that are located in certain regions. In the illustratedexample, there are no guilds within the safekeeper guild, butsafekeepers may organize according to region (e.g., states, cities, orthe like), the ability to store certain types of items (e.g., vehicles,perishables, and/or the like), or other suitable common features.

In embodiments, the overall ecosystem 2100 (including the overall loanprocess workflow) may be governed by a system-level governance 2130. Inthis example, one or more stages may be governed by a stage-levelgovernance that pertains to the participants in the stage and/or theworkflows performed in connection with the stage. For example, anauthentication stage-level governance 2132 pertains to allauthenticators 2102 and the authentication stage, the appraisalstage-level governance 2134 pertains to all appraisers 2104 and theappraisal stage, the safekeeping stage-level governance 2136 pertains toall safekeepers 2106 and the safekeeping stage, the lending stage-levelgovernance 2138 pertains to lenders (not shown) and the loan negotiationand repayment stages, and the like. As discussed, the stage-levelgovernances 2132, 2134, 2136, 2138 can refine the system-levelgovernance 2130 and may add rules and regulations that do not contradictthe system-level governance 2130. Similarly, a watch guild-levelgovernance pertains 2142 to the watch authentication guild 2112-1, butdoes not pertain to the other authentication guilds 2112-2 . . . 2112-N.The watch guild-level governance 2142 may include rules that furtherrefine the system-level governance 2130 and/or add rules and regulationsto the authentication stage-level governance 2132. In the example, aRolex sub-guild governance 2144 may be created by the members of theRolex authentication sub-guild 2122. The Rolex sub-guild governance 2144defines additional rules and regulations that apply to members of theRolex sub-guild 2122 when performing authentication of Rolex® watches,but that do not apply to other members of the watch authentication guild2112-1. It is noted that the sub-guilds do not need a sub-guildgovernance and may use the guild-level governance of the guild fromwhich the sub-guild was formed. More detailed discussion of guilds andgovernances are described below.

Referring back to FIG. 20, governances may define rules and regulationspertaining to different aspects of a securitized decentralized loanprocess. In embodiments, a system-level governance defines rules andregulations pertaining to the entire loan process. Examples ofsystem-level governance include loan process workflow definitions (e.g.,which stages must be performed and in what order); allowed types ofcollateral items; rules for guild formation and membership (e.g., canguilds be formed, can guilds change rules, how can guilds change rules,and/or the like); rules for managing a loan process workflow betweenstages (e.g., can an authenticator that authenticated a collateral itemappraise the same collateral item and/or safekeep the collateral item,when the loan process can progress to the next stage, and the like);rules that require guild members to stake currency (e.g., cryptocurrencyand/or fiat currency wrapped in a tokenized token) in relation toauthentication tasks, appraisal tasks, and/or safekeeping tasksinvolving a collateral item; rules for performing tasks (e.g., the typeof supporting documentation required to show consensus); rules forchanging the governance (e.g., who can vote to change governance, howvotes to change governances are conducted, and the like); rules forrewarding participants (e.g., any requirements and/or restrictionsrelating to amounts or percentages of payments that can be made inperforming a specific task, regulatory requirements for differentjurisdictions); and/or other suitable rules and regulations.

In embodiments, a system-level governance may include references to oneor more respective loan process smart contracts 2022 that are stored onthe distributed ledger 2016. A loan process smart contract 2022 mayenforce one or more aspects of the system-level governance for instancesof the decentralized loan process, including, for example, initiatingeach stage of the loan process when a previous stage is completed inaccordance with a loan process workflow defined in the system-levelgovernance. In embodiments, a loan process smart contract 2022 includesconditional logic that, once instantiated, listens (e.g., using an eventlistener thread) for a notification from a stage-level smart contractthat indicates that the stage was successfully completed. In response toa stage being completed, the loan process smart contract 2022 may theninitiate a next stage in the loan workflow process. For instance, anexample loan process workflow may be defined as including a requeststage where the borrower requests to collateralize one or more items,followed by an authentication stage where one or more authenticatorsauthenticate the one or more items, followed by an appraisal stage wherethe authenticated items are appraised, followed by a safekeeping stagewhere the appraised items are stored in escrow with a trustedsafekeeper, a tokenization stage where the ledger management system 104(or another suitable component) generates VIRLs of the one or moreescrowed items, generates a collateral token by tokenizing the VIRLs ofthe escrowed items, and locks the collateral token (e.g., in an escrowaccount on a distributed ledger 2016), a lending stage where a loan isnegotiated and accepted by the borrower and a lender, a repayment stagewhere the loan is repaid by the borrower, and a post-loan stage wherethe collateral token is unlocked and returned to the borrower orliquidated if the borrower defaults on the loan. In facilitating thisexample loan process workflow, the loan process smart contract 2022 maybe configured with conditional logic that determines whether a currentstage has been successfully completed and if so to initiate a next stagein the loan process workflow. In embodiments, initiating a next stage ofthe loan process workflow may include instantiating an instance of astage-level smart contract (e.g., an authentication smart contract 2028,an appraisal smart contract 2030, a safekeeping smart contract 2032, ora loan smart contract 2034), whereby the instantiated instance of thestage-level smart contract performs a stage-specific workflow and issuesa notification that is received by the loan process workflow when thestage-specific workflow is completed successfully or unsuccessfully. Inembodiments, a loan process smart contract 2022 may perform one or moretasks that are described as being performed by other types of smartcontracts. For example, loan process smart contracts 2022 may beconfigured to facilitate loan negotiations and loan signing, monitoringrepayment of the loan, determining default events, triggeringliquidation events, awarding participants with rewards, and/or the like.

The system-level process governance may include additional rules andrequirements, examples of which are provided throughout the disclosure.For example, the system-level process governance may include rules thatpreclude a single entity serving as an authenticator and appraiser, thatrequire authenticators, appraisers, and/or safekeepers to stake at leasta percentage of the loan value (e.g., to prevent manipulation of thesystem), and/or other rules that pertain to a decentralizing the loanprocess, reducing the likelihood of fraud, promoting trust, maximizingvalue for the participants, minting tokens, and/or the like. Inembodiments, at least a portion of the system-level process governanceis implemented by a loan process smart contract 2022. In embodiments,the loan process governance smart contract may include conditional logicthat determines whether each respective stage was successfullycompleted, and if so, triggers the next action in the loan process.

In embodiments, a stage-level governance defines rules and regulationspertaining to a respective stage in the loan process, such that eachstage of a loan process may be executed in accordance with one or morerespective stage-level governances. It is appreciated that in someembodiments, a stage-level governance may apply to two stages. Forexample, the authentication stage may comport to a stage-levelauthentication governance that defines rules for any authenticationtasks performed in connection with a decentralized loan process, theappraisal stage may comport a stage-level appraisal governance thatdefines rules for any appraisal tasks performed in connection with thedecentralized loan process, the safekeeping stage may comport astage-level safekeeping governance that defines rules for anysafekeeping tasks performed in connection with the decentralized loanprocess, a VIRL stage-level governance that defines rules for generatinga VIRL of a collateral item, a tokenization stage-level governance thatdefines rules for generation a token of a VIRL of a collateral item (insome embodiments, the VIRL stage and the tokenization stage may betreated as a single stage), a loan governance that defines rules forrequesting and negotiating a loan, and/or any other suitable stage-levelgovernances.

In embodiments, a stage-level governance may further refine rules setforth in the system-level governance and/or may include additional rulesthat pertain to the stage. For example, a stage-level governance mayfurther refine rules and/or regulations from the system levelgovernance, such as further refinements of adding and/or removing guildmembers; further refinements on how guild members stake currency inrelation to a guild-specific task (e.g., authentication task, appraisaltask, or safekeeping task); further refinements on what types ofevidence are needed to support an authentication task; or the like. Forexample, the system-level governance may state that new members must bevoted into any guild and may be removed by at least a 60% majority butmay not define any other specifics. In this example, the authenticationstage-level governance rules may define a first voting scheme for votingin and removing members from authentication guilds, while the appraisalstage-level governance may define a second scheme for voting in andremoving members from the appraisal guilds. For example, theauthenticators may have a one-member-one-vote voting scheme where a newmember may be added to the guild with a simple majority vote and removedwith a 60% majority vote, where the appraisers may have a token-basedvote, where each guild member has a certain amount of guild tokens 2044,whereby each guild member's voting power is proportionate to the amountof guild tokens 2044 the guild member owns. In the second scheme, moresenior or active members have more voting power than less senior or lessactive guild members. In embodiments, the stage-level governance mayfurther define the types of documentation and supporting data requiredby the guilds in that stage. In this example, the authenticationstage-level governance may further refine this rule to require that anauthenticator fill out an authentication report and provide photographicevidence to support the report. Similarly, the appraisal stage-levelgovernance may further refine this rule to require that an appraiserfile an appraisal report that indicates an appraised value and providedocumentary evidence of past sales of similar items to support theappraised value. In this example, the safekeepers stage-level governancemay further refine this rule to require that the safekeeper providephotograph evidence of the item in safe storage and fill out asafekeeping report that indicates any damage that was visible when theitem was deposited by the owner (e.g., the borrower) and a verificationby the owner of the item of said visible damage. Furthermore, theappraisal stage-level governance may further define that an appraisalreport include a liquidation value of a collateral item in addition tothe appraised value of the collateral item, where the liquidation valueindicates a low-end price that the collateral item would be expected tobe sold for (e.g., in a short-notice liquidation event or at a set pricesale to achieve a quick liquidation sale).

As mentioned, a stage-level governance may also define new rules andregulations, to the extent those new rules and regulations do notcontradict or otherwise vitiate the system-level governance. Forexample, assuming no such rules are defined in the system-levelgovernance, a stage-level governance may define rules on how astage-specific task is performed. For example, with respect to theauthentication stage, the authentication stage-level governance mayrequire a primary authenticator to make a determination on theauthenticity of a collateral item and at least one other authenticator(acting as a “secondary authenticator) to validate the primaryauthenticator's determination on the authenticity of the item. In thisexample, the stage-level governance may further define that the primaryauthenticator gets a certain percentage (e.g., 60% or 70%) of theauthentication fees/rewards and the remaining amount is split amongstthe one or more secondary authenticators. Furthermore, in this example,the authentication stage-level governance may refine the system-levelrequirement for authenticators to stake currency tokens by defining anallocation of risk to the primary authenticator and the other secondaryauthenticators (e.g., primary authenticator stakes 60% or 70% of theloan amount (assuming a loan is agreed to) and the secondaryauthenticators evenly split the remaining portion of the loan amount. Inanother example, the appraisal stage-level governance may define themechanics and workflows of an appraisal. For example, the governance maydefine the manner by which appraisal tasks are assigned to appraisersand that any appraisal must be validated by one or more additionalappraisers. In this example, the appraisal stage-level governance mayfurther refine the manner by which primary and secondary appraisers arerewarded and/or the amount of currency the primary and secondaryappraisers must stake to secure their appraisals. In another example,the safekeepers stage-level governance may define additional rules forsafekeeping of certain types of collateral items. For example, if itemsrequire temperature-controlled storage, the safekeeping stage-levelgovernance may define a rule that requires that a safekeeper provideproof of such temperature-controlled storage. In another example, if thecollateral item is a vehicle, the safekeeping stage-level governance maydefine a rule that requires that a safekeeper provide evidence of themileage of the vehicle on the day it was first received and on the dayit is repossessed by the rightful owner (e.g., the borrower or buyer vialiquidation). The stage-level governances may include additional oralternative refinements of system levels rules and regulations and/oradditional or alternative definitions of rules and/or requirements thatwere not indicated in the system level governance.

In embodiments, some stage-level governances may include form templatesthat are used in connection with the stage or references thereto (e.g.,an address where the form templates may be obtained). In some exampleembodiments, the authentication stage-level governance may include areference to an authentication form template that may be used byauthenticators when performing an authentication task. The form templatemay include a set of fields that are to be filled out by anauthenticator that is tasked with authenticating a collateral item, suchthat the authenticator completes the form and submits the form to theauthentication system 804, the authenticator smart contract 2028, and/ora loan process smart contract 2022. In filling out the form, theauthenticator can provide an opinion as to the authenticity of an itemand may provide an analysis that supports the opinion. The form mayinclude instructions to provide supporting evidence, such asphotographs, serial numbers, videos, or the like. In some exampleembodiments, the appraisal stage-level governance may include areference to an appraisal form template that may be used by appraiserswhen performing an appraiser task. Assuming that authentication isperformed before appraisal, the appraiser can trust that the item isauthentic but may require inspection of either the item itself orphotographs and/or video of the item to provide a proper assessment. Theappraiser form may include a set of fields that are to be filled out byan appraiser that is tasked with appraising the collateral item, suchthat the appraiser completes the form and submits the completed form tothe authentication system 804 and/or to an appraisal smart contract). Infilling out the form, the appraiser can provide an appraised value andmay provide an analysis that supports the appraised value. The form mayinclude instructions to provide supporting evidence, such as evidence ofpast sales of similar items, bluebook values, auction data, or the like.In some example embodiments, the safekeeping stage-level governance mayinclude a reference to a safekeeping form template that may be used bysafekeepers when performing a safekeeping task. In some embodiments, theform may require the appraiser to provide a liquidation value of thecollateral item in addition to the appraised value. The liquidationvalue may be a low-end valuation of the collateral item, such as if thecollateral item needs to be quickly liquidated. The liquidation value incombination to the appraised value may provide a potential lender anopportunity to assess the risk associated with lending the money giventhe collateral item's appraised value and liquidation value. The formmay include a set of fields that are to be filled out by a safekeeperthat is tasked with safekeeping the collateral item, such that theauthenticator completes the form and submits it (e.g., to the collateralmanagement system 802 and/or to a safekeeping smart contract). Infilling out the form, the safekeeper can provide a condition of thecollateral item when it was received and verify that the collateral itemis being stored at a physical location that has adequate precautions tosecure the collateral item. The form may include instructions to providesupporting evidence, such as photographs of the collateral item(including any visible damage). It is appreciated that the formtemplates are provided for example and additional or alternative formtemplates may be used during the various stages of a decentralized loanprocess. Furthermore, some guilds may further refine a form template fora particular type of collateral item. In these scenarios, theguild-refined form templates may be used in connection with a respectivetask in lieu of the form templates defined in the stage-levelgovernance. It is noted that other stage-level governances may includeother form templates. Furthermore, it is appreciated that someguild-level governances and/or sub-guild-level governances may includeor reference form templates that are to be used by members of the guildor sub-guild in lieu of form templates defined in the stage-levelgovernance or if the stage-level governance does not include orreference a broader form template.

In some embodiments, the stage-level governances may include referencesto one or more smart contracts that are used in connection withstage-level tasks and/or managing guilds that participate in the stage.These smart contracts may include stage-level governance smart contracts2024 corresponding to the managing the participants of respective stagesthat enforce the stage-level governance of the respective stage as wellas any relevant rules and regulations defined in the system levelgovernance. In embodiments, stage-level governance smart contracts 2024may be configured to enforce the mechanics of a particular stage. Forexample, the stage-level governance of a particular stage may requirethat changes to the governance be voted on by all participants in thestage and may use a stage-level governance smart contract 2024 toenforce the voting process. In this example, the authenticators (acrossall guilds) may wish to change the authentication stage governance torequire an authentication fee that is paid by a borrower to anauthenticator (in addition to the reward paid to the authenticator whena loan process is successfully completed) so that an authenticator maystill get paid when an item is determined to be fake or if the borrowerdecides not to enter into a loan agreement (which would prevent theauthenticator from being paid out a reward for participating in a loantransaction). The stage-level governance 2024 may require that theauthenticators have a supermajority (e.g., ⅔ majority) vote to amend thestage-level governance and must further receive approval from a decisionmaker affiliated with a central authority to make such amendments. Inthis example, a stage-level governance smart contract 2024 may include alistening thread that receives votes from authenticators and determineswhether a super majority voted to amend the authentication stage-levelgovernance. If so, the smart contract may perform an action to amend theauthentication stage-level governance and may generate a blockindicating the results of the vote that is written to a correspondingdistributed ledger 2014. While this example was described with respectto the authentication stage and for voting, stage-level governance smartcontracts 2024 may be configured to enforce other aspects of the variousstage-level governances.

Furthermore, in example embodiments, stage-level governances may includereferences to respective smart contracts that are used to managestage-level events and transactions. For example, the authenticationstage-level governance may include a reference to an authenticationsmart contract 2028 that is used to facilitate authentication tasksperformed in connection with a loan process; the appraisal stage-levelgovernance may include a reference to an appraisal smart contract 2030that is used to facilitate appraisal tasks performed in connection witha loan process; the safekeeping stage-level governance may include areference to an safekeeping smart contract 2032 that is used tofacilitate appraisal tasks performed in connection with a loan processsafekeeping tasks performed in connection a loan process; a lendingstage level governance may include a reference to loan smart contract2034 that is used to manage the loan agreement and loan repayment stage;and the like. In some embodiments, the loan workflow may include apre-loan liquidation stage (discussed below) that is governed by apre-loan liquidation stage-level governance. In these embodiments, thepre-loan liquidation stage-level governance may include a reference to apre-loan liquidation smart contract, which is discussed in greaterdetail below.

In example embodiments, the authentication stage-level governance mayinclude a reference (e.g., an address) of an authentication smartcontract 2028 that may be used for authentication tasks. The referencemay define an address that can be used to retrieve an authenticationsmart contract 2028 (e.g., from a distributed ledger 2016). In theseembodiments, a loan process smart contract 2022, an authenticator device2004, and/or the tokenization platform 100 may instantiate an instanceof the authentication smart contract 2028 in response to anauthenticator being assigned a new authentication task and/or theauthenticator accepting the new authentication task via an authenticatordevice 2004. Once instantiated, the instance of the authentication smartcontract 2028 may be written to a distributed ledger 2016, where theauthentication smart contract instance executes to manage theauthentication task. In embodiments, an authentication smart contract2028 may be configured to receive input from an authenticator device2004, a borrower device 2002, and/or the collateral management system804 and may include conditional logic that determines whether all therequired steps were performed in connection with an authentication taskbased on the received input.

FIG. 22 illustrates a set of operations of an example method 2200 thatmay be executed to perform an authentication workflow. The method 2200may be executed by a smart contract, such as an authentication smartcontract 2028 or a loan process smart contract 2022. For purposes ofexplanation, the method 2200 is described as being performed by theauthentication smart contact.

At 2202, an instance of an authentication smart contract 2028 mayreceive confirmation of recipient of collateral item from anauthenticator device. In some scenarios, the collateral item isphysically sent to a primary authenticator to perform a task. In such ascenario, the primary authenticator may confirm receipt of thecollateral item using the authenticator device 2004. In theseembodiments, the authenticator can provide images of the collateral itemand may note any damage that is visible to the item. Alternatively, theprimary authenticator may be sent a VIRL of the collateral item. Inthese embodiments, the VIRL may include ultra-high-resolution images ofthe collateral item and/or other media that may aid the authenticator inperforming the authentication task.

At 2204, the authentication smart contract instance may receive anauthentication report and supporting documentation from the primaryauthenticator. In these embodiments, a primary authenticator may berequired to generate an authentication report in accordance with theauthentication stage-level governance and/or the guild level governanceof the authentication guild to which the authenticator belongs. In someembodiments, the primary authenticator may use a form template that isincluded in the stage authentication stage-level governance and/or theguild level governance to generate the report. In the report mayindicate the primary authenticator's conclusion (e.g., whether the itemis authentic or fake) and reasons for the conclusion. The supportingdocumentation may include photographs, serial numbers, test results, orlike to support the authenticator's conclusion. Once the authenticatorprovides the authentication report, the report and supportingdocumentation may be provided to one or more secondary authenticators(if required by the stage-level governance).

At 2206, the authentication smart contract instance receivesverification from one or more secondary authenticators. In someembodiments, the authentication smart contract 2028 may includeconditional logic that requests the opinions of secondary authenticatorsin response to receiving the primary authenticator's report. In someembodiments, the smart contract instance (or the primary authenticator)may provide the primary authenticator's report and supporting evidenceto the secondary authenticators (after they are assigned to the task)and may listen for responses from the secondary authenticators. Oncereceived, the authentication smart contract 2028 may determine whether arequisite number of secondary authenticators provided a supportingopinion and, if so, the authentication smart contract instance executeslogic to determine whether the secondary authenticators verified theprimary authenticator's opinion as to the authenticity of the collateralitem.

At 2208, a data block based on the authentication report, the supportingdocumentation, and the secondary authenticator's opinions is generatedand the data block may be written to a distributed ledger 2016. In someembodiments, the authentication smart contract may generate the datablock and write the data block to the distributed ledger. Alternatively,the authentication smart contract may transmit the authenticationreport, the supporting documentation, and the secondary authenticator'sopinions to the ledger management system 202 (or another suitablesystem), which in turn may generate the data block and write the datablock to the distributed ledger.

At 2210, the authentication smart contract instance may providenotification to a loan process smart contract 2022 indicating theresults of the authentication task. In particular, the authenticationsmart contract may provide a notification to the loan process smartcontract 2022 indicating whether the item was deemed authentic by theprimary authenticator and the secondary authenticator(s). If so, theauthentication smart contract instance may continue to proceed throughthe authentication workflow until the authenticator(s) that participatedin the authentication process are rewarded (e.g., from the repaymentfunds and/or the proceeds of a liquidation event). If not, theauthentication smart contract instance may end the authentication task.

At 2212, the authentication smart contract instance may lock an amountof currency from the authenticators to secure the authentication in casethe item is deemed inauthentic. In some embodiments, the authenticationsmart contract instance may enforce a requirement set forth in theauthentication stage-level governance and/or guild-level governance ofthe authenticator to lock a certain amount of currency (e.g.,currency/tokenized tokens) when the authenticator(s) deem the itemauthentic so as to provide a greater amount of security to a lender. Inthis way, authenticators will have less incentive to authenticate itemsthat might be fake. In embodiments, the amount that is locked may beequal to or a percentage of the loan amount, the total repayment amount,the appraised value, or another suitable value, where the amount to belocked is defined in accordance with the appraisal-stage governance. Insome embodiments, the locked currency tokens are returned to theauthenticators during the course of repayment, such that the amount oflocked currency from the authenticators that does not exceed theremaining balance of the loan as the locked currency provides acontingency should an authenticated item later be discovered to be fake.

At 2214, the authentication smart contract instance may transfer areward amount to the authenticators that participated in theauthentication task upon repayment of the loan. Once the loan process iscomplete (e.g., after repayment of the loan and collateral item isreturned to borrower; after a liquidation event with a prescribed amountof time after the sale for the buyer of the collateral time to inspectthe collateral item; and/or if the buyer decides to not engage in a loanand wishes to retake possession of the collateral item) may issue areward to the primary authenticator and any secondary authenticatorsthat participated in the authentication task. For example, theauthenticators may be rewarded with a percentage of the loan orrepayment amount, a predefined fee, and/or the like. Once the loanprocess is complete, the instance of the authentication smart contractmay be deconstructed.

The example of FIG. 22 is provided as an example authenticationworkflow. Other authentication workflows may be executed in connectionwith authentication tasks. Furthermore, within respective authenticationguilds, the members of the respective authentication guilds can refinethe authentication workflows and/or authentication smart contracts toimprove the authentication of certain tasks, provided such refinementsare in accordance with the authentication stage-level governance.

Referring back to FIG. 20, an appraisal stage-level governance mayinclude a reference (e.g., an address) of an appraisal smart contract2030 that may be used for appraisal tasks. The reference may define anaddress that can be used to retrieve an appraisal smart contract 2030(e.g., from a distributed ledger 2016). In these embodiments, a loanprocess smart contract 2022, an appraiser device 2006, and/or thetokenization platform 100 may instantiate an instance of the appraisalsmart contract 2030 in response to an appraiser being assigned a newappraisal task and/or the appraiser accepting the new appraisal task viaan appraiser device 2006. Once instantiated, the instance of theappraiser smart contract 2030 may be written to a distributed ledger2016, where the appraisal smart contract instance executes to manage theappraisal task. In embodiments, an appraisal smart contract 2030 may beconfigured to receive input from an appraiser device 2006, a borrowerdevice 2002, and/or the tokenization platform 100 and may includeconditional logic that determines whether all the required steps wereperformed in connection with an appraisal task based on the receivedinput.

FIG. 23 illustrates an example set of operations of a method 2300 thatmay be executed to perform an appraisal workflow. The method 2300 may beexecuted by a smart contract, such as an appraisal smart contract 2030or a loan process smart contract 2022. For purposes of explanation, themethod 2300 is described as being performed by the appraisal smartcontact.

At 2302, an instance of an appraisal smart contract 2030 may receiveconfirmation of recipient of collateral item from an appraiser device2006. In some scenarios, the collateral item is physically sent to aprimary appraiser to perform a task. In such a scenario, the primaryappraiser may confirm receipt of the collateral item using the appraiserdevice 2006. In these embodiments, the appraiser can provide images ofthe collateral item and may note any damage that is visible to the item.Alternatively, the primary appraiser may be sent a VIRL of thecollateral item. In these embodiments, the VIRL may includeultra-high-resolution images of the collateral item and/or other mediathat may aid the authenticator in performing the appraisal task. In someembodiments, the appraiser may receive additional information, such as aconfirmation that a set of authenticators authenticated the collateralitem.

At 2304, the appraisal smart contract instance may receive an appraisalreport and supporting documentation from an appraiser device 2006 of theprimary appraiser. In these embodiments, a primary appraiser may berequired to generate an appraisal report in accordance with theappraisal stage-level governance and/or the guild level governance ofthe appraisal guild to which the appraiser belongs. In some embodiments,the primary appraiser may use a form template that is included in theappraisal stage-level governance and/or the guild level governance ofthe appraiser's appraisal guild to generate the report. In the reportmay indicate an appraised value determined by the appraiser anddocumentation that support the appraised value. The supportingdocumentation may include links to bluebook values of similar items,screenshots of sales of similar items, historical data relating to salesof similar items, and/or other suitable information to support theappraiser's appraised value. Once the appraiser provides the appraisalreport, the report and supporting documentation may be provided to oneor more secondary appraiser(s) (if required by the appraisal stage-levelgovernance). In some embodiments the appraisal stage-level governance ora guild-level governance of the appraiser may require the appraiser tosubmit a liquidation value in the appraisal report in addition to theappraised value.

At 2306, the appraisal smart contract instance receives verificationfrom one or more secondary appraisers. In some embodiments, theappraisal smart contract 2030 may include conditional logic thatrequests the opinions of a secondary appraiser in response to receivingthe primary appraiser's report. In some embodiments, the appraisal smartcontract 2030 (or the primary appraiser) may provide the primaryappraiser appraiser's report and supporting evidence to the secondaryappraisers (after they are assigned to the task) and may listen forresponses from the secondary appraisers. Once received, the appraisalsmart contract 2030 may determine whether a requisite number ofsecondary appraisers confirmed the primary appraiser's valuation.

At 2308, a data block based on the appraisal report, the supportingdocumentation, and the secondary appraiser's opinions is generated andthe data block may be written to a distributed ledger 2016. In someembodiments, the appraisal smart contract may generate the data blockand write the data block to the distributed ledger 206. Alternatively,the appraisal smart contract may transmit the appraisal report, thesupporting documentation, and the secondary appraisers' opinions to theledger management system 202 (or another suitable system), which in turnmay generate the data block and write the data block to the distributedledger 2016. In some embodiments, the data block may further include theliquidation value of the collateral item as determined by the appraiser.

At 2310, the appraisal smart contract may provide notification to a loanprocess smart contract 2022 indicating the results of the appraisaltask. In particular, the appraisal smart contract may provide anotification to the loan process smart contract 2022 indicating theappraised value. Assuming the borrower agrees to a loan agreement, theappraisal smart contract may continue to proceed through the appraisalworkflow until the appraiser(s) that participated in the appraisalprocess are rewarded (e.g., from the repayment funds and/or the proceedsof a liquidation event). If the borrower does not form a loan contractand decides to end the loan process, the appraisal smart contract mayend the appraisal task.

At 2312, the appraisal smart contract may lock an amount of currencyfrom the appraisers to secure the appraisal in case the item is notliquidated at or more than the appraised value provided by theappraiser. In some embodiments, the appraisal smart contract 2030 mayenforce a requirement set forth in the appraisal stage-level governanceand/or guild-level governance of the appraiser's guild to lock a certainamount of currency (e.g., currency/tokenized tokens) when theappraiser(s) provide an appraised value so as to provide a greateramount of security to a lender. In this way, the appraiser will haveless incentive to appraise items at higher prices to improve the chancesthat a loan agreement will be entered into. In embodiments, the amountthat is locked may be equal to or a percentage of the loan amount, thetotal repayment amount, the appraised value, or another suitable value,where the amount to be locked is defined in accordance with theappraisal-stage governance. In some embodiments, the locked currencytokens are returned to the appraisers during the course of repayment,such that the amount of locked currency from the appraisers does notexceed the remaining balance of the loan as the locked currency providesa contingency should an appraised item be sold at a liquidation event ata value that is less than the appraised value.

At 2314, the appraisal smart contract may transfer a reward amount tothe appraisers that participated in the appraisal task upon repayment ofthe loan. Once the loan process is complete (e.g., after repayment ofthe loan and collateral item is returned to borrower or after aliquidation event) may issue a reward to the primary appraiser and anysecondary appraisers that participated in the appraisal task. Forexample, the appraisers may be rewarded with a percentage of the loan orrepayment amount, a predefined fee, and/or the like. Once the loanprocess is complete, the instance of the appraisal smart contract may bedeconstructed.

The example of FIG. 23 is provided as an example appraisal workflow.Other appraisal workflows may be executed in connection with appraisaltasks. Furthermore, within respective appraisal guilds, the members ofthe respective appraisal guilds can refine the appraisal workflowsand/or appraisal smart contracts to improve the appraisal of certaintasks, provided such refinements are in accordance with the appraisalstage-level governance.

Referring back to FIG. 20, a safekeeping stage-level governance mayinclude a reference (e.g., an address) of a safekeeping smart contract2032 that may be used for appraisal tasks. The reference may define anaddress that can be used to retrieve a safekeeping smart contract 2032(e.g., from a distributed ledger 2016). In these embodiments, a loanprocess smart contract 2022, an appraiser device 2006, and/or thetokenization platform 100 may instantiate an instance of the safekeepingsmart contract 2030 in response to a safekeeper being assigned a newappraisal task and/or the safekeeper accepting the new safekeeping taskvia a safekeeping device 2008. Once instantiated, the instance of theappraiser smart contract 2030 may be written to a distributed ledger2016, where the safekeeping smart contract instance executes to managethe safekeeping task. In embodiments, a safekeeping smart contract 2032may be configured to receive input from a safekeeper device 2008, aborrower device 2002, and/or the tokenization platform 100 and mayinclude conditional logic that determines whether all the required stepswere performed in connection with a safekeeping task based on thereceived input.

FIG. 24 illustrates an example set of operations of a method 2400 thatmay be executed to perform a safekeeping workflow. The method 2400 maybe executed by a smart contract, such as a safekeeping smart contract2032 or a loan process smart contract 2022. For purposes of explanation,the method 2400 is described as being performed by an instance of asafekeeping smart contact.

At 2402, an instance of a safekeeping smart contract 2032 may receiveconfirmation of recipient of collateral item from a safekeeper device2008. In some scenarios, the collateral item is sent to a safekeeper forsafekeeping during the pendency of a loan. Alternatively, the item maybe deposited with the safekeeper by another party, such as the borrower.In either scenario, the safekeeper may confirm receipt of the collateralitem using the appraiser device 2006. In these embodiments, thesafekeeper can document the collateral item upon receipt, such as bytaking images of the collateral item and noting any damage that isvisible to the item.

At 2404, the safekeeping smart contract instance may receive asafekeeping report and supporting documentation from a safekeeper device2008 of the safekeeper. In these embodiments, a safekeeper may berequired to generate a safekeeping report in accordance with thesafekeeping stage-level governance and/or the guild level governance ofa safekeeper guild to which the safekeeper belongs (to the extent suchguild exists). In some embodiments, the safekeeper may use a formtemplate that is included in the safekeeper stage-level governanceand/or the guild level governance of the safekeeper guild to generatethe report. In the report, the safekeeper may indicate that the item wasreceived, a condition in which it was received, any damage that isvisible to the collateral item, where the item is being stored, whetherthe item is in secured storage, and/or other relevant information. Inembodiments, the safekeeper may provide supporting documentation, suchas images of the collateral item, including any documentation ofnoticeable damage, images of the item in storage, and the like. Once thesafekeeper provides the safekeeping report, the safekeeper report andsupporting documentation may be written to a distributed ledger 2016.

At 2406, a data block based on the safekeeping report and the supportingdocumentation, and the secondary appraiser's opinions is generated andthe data block may be written to a distributed ledger 2016. In someembodiments, the safekeeping smart contract may generate the data blockand write the data block to the distributed ledger 206. Alternatively,the safekeeping smart contract may transmit the safekeeping report, thesupporting documentation, and the secondary appraisers' opinions to theledger management system 202 (or another suitable system), which in turnmay generate the data block and write the data block to the distributedledger 2016.

At 2408, the safekeeping smart contract instance may lock an amount ofcurrency from the safekeeper to mitigate the risk associated withproperty loss or damage during safekeeping. In some embodiments, thesafekeeping smart contract 2030 may enforce a requirement set forth inthe safekeeping stage-level governance and/or a guild-level governanceto lock a certain amount of currency (e.g., currency/tokenized tokens)when an item is safekept so as to provide a greater amount of securityto a lender. In embodiments, the amount that is locked may be equal toor a percentage of the loan amount, the total repayment amount, theappraised value, or another suitable value, where the amount to belocked is defined in accordance with the safekeeping-stage governance.In some embodiments, the locked currency tokens are returned to thesafekeeper during the course of repayment, such that the amount oflocked currency from the safekeeper does not exceed the remainingbalance of the loan as the locked currency provides a contingency shoulda stored collateral item be damaged or lost. At 2410, the safekeepingsmart contract instance may provide notification to a loan process smartcontract 2022 indicating that the collateral item has been secured andthat event records 2052 relating to the safekeeping task have beenwritten to the distributed ledger 2016.

At 2412, the safekeeping smart contract instance may facilitate thetransfer of possession of the collateral item to the owner of thecollateral token 2042 corresponding to the collateral item upon aredemption event. In embodiments, the redemption of a collateral token2042 may be performed in accordance with a collateral redemptionworkflow, which may be executed off-chain (e.g., by a computing systemof a trusted-third party, such as the tokenization platform 100) and/oron-chain (e.g., by instances of one or more smart contracts). Inembodiments, the collateral redemption workflow may include, but is notlimited to, the following operations: receiving a request to redeem acollateral item indicated by a collateral token 2042 from a user device;verifying the user that is attempting to redeem the collateral token2042 is the rightful owner of the collateral token 2042 based onownership data 2052 stored on a distributed ledger 2016; identifying asafekeeper of the collateral item indicated by the collateral token 2042from the distributed ledger 2016 and/or the loan process smart contract2022; transmitting a redemption notification to a safekeeper device 2008of the identified safekeeper that the rightful owner has redeemed thecollateral token 2042; receiving a confirmation notification from thesafekeeper device 2008 of the identified safekeeper indicating that therightful owner of the collateral token has taken ownership of thecollateral item; and burning the collateral token 2042 in response toreceiving the notification from the safekeeper (as described above). Inembodiments, the redemption workflow may include additional oralternative steps, such as receiving feedback from the redeeming ownerof the collateral item indicating that the collateral item has beenreturned in satisfactory condition and/or updating a distributed ledger2016 to indicate the occurrence and content of such feedback events(which may be used to update analytics and/or a rating of thesafekeeper).

At 2414, the safekeeping smart contract may transfer a reward amount tothe safekeeper upon repayment of the loan and/or redemption of thecollateral item. For example, the safekeeper may be rewarded with apercentage of the loan or the repayment amount, a predefined fee, and/orthe like. Once the loan process is complete, the instance of thesafekeeping smart contract may be deconstructed.

The example of FIG. 24 is provided as an example safekeeping workflow.Other safekeeping workflows may be executed in connection withsafekeeping tasks. Furthermore, within a safekeeper guild, the membersof the respective guild can refine the safekeeping workflows and/orsafekeeper smart contracts to improve the safekeeping of certain items,provided such refinements are in accordance with the safekeepingstage-level governance.

Referring back to FIG. 20, a lending stage-level governance may includea reference (e.g., an address) of a loan smart contract 2034 that may beused to monitor repayment of a loan. The reference may define an addressthat can be used to retrieve a loan smart contract 2034 (e.g., from adistributed ledger 2016). In these embodiments, a loan process smartcontract 2022, a borrower device 2002, a lender device 2010 and/or thetokenization platform 100 may instantiate an instance of the loan smartcontract 2034 in response to a loan agreement being reached. Inembodiments, the negotiation of a loan is performed by the borrower andlender off-chain (e.g., via the tokenization platform 100). In theseembodiments, the loan smart contract instance may be instantiated inresponse to the parties' agreement to the terms of a loan agreement.Once instantiated, the loan smart contract instance may be written to adistributed ledger 2016, where the loan smart contract instance executesto manage the loan repayment stage. In embodiments, a loan smartcontract 2034 may be configured to receive input from a borrower device2002, a lender device 2010, and/or the tokenization platform 100.

FIG. 25 illustrates an example set of operations of a method 2500 thatmay be executed to perform a loan repayment workflow. The method 2500may be executed by a smart contract, such as a loan smart contract 2034or a loan process smart contract 2022. For purposes of explanation, themethod 2500 is described as being performed by an instance of a loansmart contact. In the depicted example, the loan smart contract 2034 mayinstantiated upon the borrower and lender agreeing to a loan agreementoff-chain. In some embodiments, however, the loan contract 2032 may beconfigured to facilitate the negotiation of the loan as well.

At 2502, an instance of a loan smart contract 2034 may receive the loanagreement terms and may establish a repayment schedule in accordancewith the loan agreement terms. In some scenarios, the loan smartcontract 2034 may receive the loan agreement terms from a computingsystem (e.g., the tokenization platform) that facilitated thenegotiation of the loan agreement. The loan agreement terms may includea loan amount, a loan term, a loan repayment amount, an interest rate,late fee penalties, default condition definitions, and the like. Inembodiments, the loan smart contract instance may determine therepayment schedule based on the repayment amount and the loan term. Theloan smart contract instance may determine the repayment schedule suchthat the payments are equally distributed over the loan term. The loansmart contract instance may determine the repayment schedule in anyother suitable manner.

At 2504, the loan smart contract instance locks the collateral token inan escrow account and facilitates the transfer of funds from an accountof the lender to the borrower. In embodiments, once the loan agreementis in place, the loan smart contract instance may lock the collateraltoken in an escrow account for the duration of the loan repaymentperiod. Once the collateral token is locked, thereby preventing theborrower from redeeming the collateral token, the loan smart contractinstance may facilitate the transfer of funds equal to the loan amountfrom an account of the lender to an account of the buyer. In someembodiments, the loan smart contract instance may transfer the funds byupdating the ownership data 2054 of a set of currency/tokenized tokens2044 owned by the lender to reflect an account of the borrower.

At 2506, the loan smart contract instance listens for payment eventnotifications. In embodiments, the loan smart contract 2034 may beconfigured with an event listener that listens for payment eventnotifications. In some embodiments, the payment event notifications maybe received from a borrower device 2002, a lender device 2004, or atrusted third-party computing system that is facilitating repayment ofthe loan (e.g., the tokenization platform 100). In embodiments, apayment event notification may indicate an amount paid and a date and/ortime at which the payment was received.

At 2508, the loan smart contract instance may determine whether ascheduled payment was received. If the payment was not received, theloan smart contract instance may determine whether the loan is in adefault condition pursuant to the loan agreement. A loan may be in adefault condition if a borrower misses one or more payments, such thatthe loan agreement may define how many payments may be missed before theloan enters a default condition. If the loan is not in a defaultcondition, the loan smart contract instance may apply any penaltiesand/or fees to the principal balance and may continue to listen for apayment event notification.

If the loan is in a default condition, the loan smart contract instancemay initiate a liquidation of the collateral item, as shown at 2512. Insome embodiments, the loan smart contract instance may provide aliquidation request to a marketplace (e.g., marketplace system 102) thatindicates the collateral token 2042 and/or the VIRL wrapped therein. Theliquidation request may include additional data, such as an appraisedamount, appraisal records, authentication records, safekeeping records,and/or a remaining balance on the loan repayment amount. In response,the marketplace may conduct a liquidation sale. In embodiments, theliquidation sale may be a fixed price sale (e.g., set at the appraisedvalue) or an auction (e.g., starting at the remaining balance of theloan repayment amount). Once the item is liquidated and the buyer haspaid for the collateral item, the loan smart contract instance mayreceive a liquidation notification that indicates that the item wasliquidated. In response, the loan smart contract instance may initiatethe transfer of the collateral token 2042 that was used to secure thedefaulted-upon loan from the escrow account in which it was held to anaccount of the buyer of the collateral item. Once the ownership data2054 of the collateral token is updated to indicate that the collateraltoken 2042 is owned by the buyer, the buyer may then redeem thecollateral token 2042 (e.g., as described throughout the disclosure). Inembodiments, the remaining balance of the loan is paid to the lenderfrom proceeds of the sale as well as the rewards to the participants ofthe loan process (e.g., authenticators, appraisers, and/or safekeepers).At 2514, the loan smart contract instance may generate a data blockindicating a default event and may write the data block to thedistributed ledger, thereby creating a record of the default event.

If at 2508 the payment was received, the loan smart contract instancemay determine whether the loan is paid in full, as shown at 2516. If theloan is not paid in full, the loan smart contract instance may determinethe remaining balance on the loan repayment amount. In some embodiments,the loan smart contract instance may unlock currency/tokenized tokens2044 of guild members that staked the tokens in connection withperformance of their respective authentication, appraisal, andsafekeeping tasks. In embodiments, the loan smart contract instance mayunlock an amount of tokens that is proportionate to the paymentreceived, as shown at 2518. In these embodiments, the remaining lockedtokens of any guild member does not exceed the remaining balance on theloan repayment amount.

If at 2516, the loan smart contract instance determines that the loan ispaid in full, the loan smart contract instance may generate a data blockindicating a repayment event and may write the data block to thedistributed ledger, as shown at 1520. In this way, the loan smartcontract instance creates a record of the repayment event indicatingthat the loan has been paid in full. Once the loan is repaid in full,the loan smart contract instance may issue a repayment notification tothe loan process smart contract instance governing the loan and/or tothe tokenization platform 100, such that the notification initiates theawarding of rewards to the participants of the loan process (e.g.,authenticators, appraisers, and/or safekeepers).

At 2522, the loan smart contract instance may unlock the collateraltoken 2042 from the escrow account and may reinstate ownership to theborrower. In embodiments, the loan smart contract instance may updatethe ownership data 2054 of the collateral token 2042 to reflect that theborrower is once again the owner of the collateral token. Once the loanprocess is complete, the instance of the safekeeping smart contract maybe deconstructed.

The example of FIG. 25 is provided as an example loan repaymentworkflow. Other loan repayment workflows may be executed in connectionwith lending and loan repayment without departing from the scope of thedisclosure.

Referring back to FIG. 20, in some embodiments, different variations ofa decentralized loan process may include a pre-loan liquidation event. Apre-loan liquidation event may be a conditional liquidation sale that isconducted before the loan is negotiated. It is noted that the sale maybe a set-price sale where the price is set ahead of the sale or anauction sale where the collateral item is auctioned. In someembodiments, an example loan process workflow may include a requeststage, followed by an authentication stage, a safe keeping stage, and atokenization stage (in any suitable order), followed by a pre-loanliquidation stage, which is then followed by the lending stages andrepayment stage. In these example embodiments, once the collateral itemsis authenticated, escrowed and tokenized, an auction or a set-price saleis conducted for the collateral item (e.g., via the marketplace system102), whereby the buyer of the collateral item obtains an ownershipoption that is triggered upon the borrower's default (or if the borrowerdecides to forego the loan and relinquish ownership rights to the item).In this way, the borrower and lender know the true value of thecollateral item before a loan is negotiated, which determines how muchcan be borrowed by the borrower and removes the need for an appraiser.Furthermore, in some embodiments, the contingent buyer may be requiredto escrow an amount of currency/tokenized tokens 2046 equal to theamount of the purchased item (or a portion thereof) and/or prove that heor she has enough funds to cover the sale (e.g., by providing an addressof the buyer's account or providing banking information). In exchange,the contingent buyer may be rewarded with a portion of the repaymentamount should the borrower successfully repay the loan, where the rewardamount may be a flat fee, a percentage of the sale price, or aninterest-based reward.

In example embodiments, the rules and regulations surrounding a pre-loanliquidation stage are defined in a pre-loan liquidation stage-levelgovernance. In these embodiments, the pre-loan liquidation stage-levelgovernance may refine and/or define rules such as: an amount of currencythe contingent buyer must deposit to secure the contingent sale; anamount of monetary reward the contingent buyer is provided if the loanis successfully repaid; the allowed mechanics of a pre-loan liquidationevent (e.g., auctions, set-price sales, or the like); and other suitablerules and regulations.

In some embodiments, the pre-loan liquidation stage-level governance mayinclude a reference (e.g., an address) of a pre-loan liquidation smartcontract (not shown) that may be used in facilitating pre-loanliquidation events. The reference may define an address that can be usedto retrieve a pre-loan liquidation smart contract (e.g., from adistributed ledger 2016). In these embodiments, a loan process smartcontract 2022 and/or the tokenization platform 100 may instantiate aninstance of the pre-loan liquidation smart contract in response to theloan process progressing to the pre-loan liquidation stage. Inembodiments, a pre-loan liquidation smart contract may be configured toreceive input from a borrower device 2002, a contingent buyer device, aloan process smart contract 2022, loan process smart contract 2028,and/or the tokenization platform 100 (e.g., the marketplace system 102).Once instantiated, the instance of the pre-loan liquidation smartcontract may be written to a distributed ledger 2016, where the pre-loanliquidation smart contract instance executes a pre-loan liquidationworkflow that may include a pre-loan liquidation sale stage, atransaction verification stage, and a contingency resolution stage. Inexample embodiments, the pre-loan liquidation smart contract mayinitiate the sale of a collateral item during the pre-loan liquidationsale stage, initiating a pre-loan liquidation event based on acollateral token corresponding to the collateral item. Assuming that thecollateral item is sold (pursuant to a contingency), the pre-loanliquidation smart contract may execute the transaction verificationstage, where the borrower is provided an opportunity to a) reject thesale price and end the loan process; b) agree to the sell the collateralitem to the contingent buyer at the sale price and end the loan process;or c) proceed with the loan process at the given sale price. During thecontingency resolution stage, the pre-loan liquidation smart contractinstance may receive notifications relating to the state of a subsequentloan, such that if the loan is repaid in full, the pre-loan liquidationsmart contract may initiate the transfer the collateral token 2042 fromthe escrow account to the borrower and reward the contingency buyer withthe defined reward amount. Conversely, if the seller defaults, thepre-loan liquidation smart contract may transfer the collateral token2042 from the escrow account to the buyer and may transfer the agreedupon purchase price to the lender and the participants (e.g.,authenticator and safekeeper), such that any remaining balance isreturned to the borrower.

FIG. 26 illustrates an example set of operations of a method 2600 forperforming a pre-loan liquidation workflow according to some embodimentsof the present disclosure. The method 2600 may be executed by a smartcontract, such as a pre-loan liquidation smart contract or a loanprocess smart contract 2022. For purposes of explanation, the method2600 is described as being performed by an instance of a pre-loanliquidation smart contract.

At 2602, the pre-loan liquidation smart contract instance receives acollateral token 2052 (or an indicator thereof, such as a block addressof the collateral token). At 2604, the pre-loan liquidation smartcontract instance determines the VIRL corresponding to the collateraltoken 2052. In some embodiments, the pre-loan liquidation smart contractinstance may determine a VIRL identifier of the VIRL from the collateraltoken 2042 and/or from the distributed ledger 2016. In the latterscenario, the pre-loan liquidation smart contract instance may read thedata block that contains the collateral token 2042 from the distributedledger 2016 that stores the token 2042 and may obtain the VIRLidentifier therefrom.

At 2606, the pre-loan liquidation smart contract instance may provide arequest for a contingent sale of the collateral item to a marketplace(e.g., marketplace system 102). In embodiments, the request may includethe VIRL (or an indicator thereof, such as a VIRL ID or the like) and/orother documentation describing and/or showing the collateral item. Inembodiments, the contingent sale request may include other suitableinformation, such as a contingent sale type (e.g., auction or set pricesale), a location of the collateral item, a sought price for thecollateral item (if a set price sale), a minimum price for thecollateral item (if an auction), a length of the contingency (e.g., theamount of time that the borrower needs to secure and repay the loan), areward offer (e.g., a predefine reward amount or a percentage of thepurchase price, desired loan amount, or repayment amount), and/or thelike. In response the marketplace can facilitate the contingent sale,which may result in the collateral item being sold (e.g., a contingentbuyer buys the collateral item at a set price or wins an auction) with aset of contingencies or no sale.

At 2608, the pre-loan liquidation smart contract may receive the resultsof the contingent sale from the marketplace. Once the contingent sale iscompleted, the marketplace can send a sale notification to theliquidation smart contract instance indicating the results of thepre-loan liquidation event. In embodiments, the results of the pre-loanliquidation event indicate whether the item was sold, and if sold, aprice at which the item was sold (minus any fees taken by themarketplace for hosting the sale).

At 2610, the pre-loan liquidation smart contract may provide acontingent sale notification to a borrower device 2002 of the borrower(assuming a pre-loan sale of the collateral item occurred). In responseto receiving the contingent sale notification, the borrower has anoption to agree to the contingent sale to advance the loan process,refuse the contingent sale (e.g., if the sale was an auction and theagreed upon liquidation price was too low to secure a loan), or tocomplete the contingent sale (e.g., if the sale was an auction and theprice was high enough to convince the buyer to sell the collateral itemrather than seek a loan using the collateral item). If the borrowerrefuses the sale, the retains possession of the collateral token 2042,as shown at 2612. If the borrower agrees to complete the contingentsale, the pre-loan liquidation smart contract may initiate the transferthe collateral token 2042 to the contingent buyer and the transfer ofthe proceeds of the sale to the buyer (e.g., a purchase amount incurrency/tokenized tokens or fiat currency minus any fees taken by themarketplace), as shown at 2614. In the event that the borrower agrees tothe contingent sale, the pre-loan liquidation smart contract may lockthe collateral item in an escrow account, as shown at 2616.

At 2618, the pre-loan liquidation smart contract instance may escrow adefined amount of currency from the contingent buyer based on thecontingent sale amount. During the transaction verification stage, thepre-loan liquidation smart contract may be configured to ensure that thecontingent buyer can pay the sale price, should the loan go intodefault. In some embodiments, the pre-loan liquidation smart contractmay require the contingent buyer to escrow currency/tokenized tokens2046 equal to the full sale amount or a portion of the full sale amount(e.g., 50%), which may be achieved by locking the defined amount ofcurrency/tokenized tokens 2046 from an account of the contingent buyerin an escrow account. Alternatively, the contingent buyer may provideevidentiary documents (e.g., bank statements, tax statements, or thelike) to prove a liquidity threshold is met, thereby providingconfidence that the contingent buyer can afford to complete the sale,should the borrower default. In these embodiments, the pre-loanliquidation smart contract instance may write the evidentiary documentsto a distributed ledger 2016.

At 2620, the pre-loan liquidation smart contract instance may resolvethe contingency sale. Once the borrower agrees to the terms and thebuyer confirms that they can pay the sale price, the pre-loanliquidation smart contract instance may execute a contingency resolutionstage. During the contingency resolution stage, the pre-loan liquidationsmart contract instance may monitor the loan process to verify that theborrower was able to secure the loan. If the borrower is unable tosecure a loan and decides to end the loan process, the pre-loanliquidation smart contract may initiate a refund of any escrowed funds(and potentially a reward fee) to the conditional buyer and may initiatethe transfer of the collateral token 2042 from the escrow account to theaccount of the borrower. Assuming the borrower does enter into a loanagreement, the pre-loan liquidation smart contract may monitor therepayment of the loan. In some embodiments, the pre-loan liquidationsmart contract may receive a default notification if the borrower isdeemed to have defaulted on repaying the loan pursuant to the terms ofthe loan agreement (e.g., from the loan process smart contract 2022 or aloan smart contract 2034 governing the loan). In response, the pre-loanliquidation smart contract may provide a notification to the contingentbuyer to pay any remaining balance on the collateral item (assuming theentire amount was not put in escrow by the buyer). Upon verifying thatthe contingent buyer has paid the full balance of the price or if thebuyer had escrowed the entire sale price at the time of the contingentsale, the pre-loan liquidation smart contract may issue a notificationthat the sale amount has been secured (e.g., to the loan process smartcontract instance 2022 and/or the loan smart contract 2034) and mayinitiate the transfer of the collateral token 2052 to the contingentbuyer. It is noted that the repayment of the funds to the lender and/orissuing of rewards to the safekeeper and authenticator(s) from theproceeds of the contingent sale may be handled via a different workflow.In some embodiments, the pre-loan liquidation smart contract may receivea notification of a repayment event when the borrower successfullyrepays the entire repayment amount of the loan (the loan amount and anyinterest and fees). Upon receiving the repayment notification, thepre-loan liquidation smart contract instance may initiate the transferof any staked funds back to the contingent buyer and may initiate atransfer of a reward (e.g., currency/tokenized tokens 2046) to anaccount of the contingent buyer as a reward for the buyer staking thefunds to help secure the loan vis-à-vis by participating in thecontingency sale. In embodiments, the reward amount may be paid by thelender and/or may have been held in escrow from the payments made by theborrower to the lender during the repayment stage of the loan. Thepre-loan liquidation workflow may include additional or alternativestages without departing from the scope of the disclosure.

The example of FIG. 26 is provided as an example pre-loan liquidationworkflow. Other pre-loan liquidation workflows may be executed inconnection with pre-loan liquidation events.

Referring back to FIG. 20, according to some embodiments of the presentdisclosure, the smart contracts associated with respective stages of adecentralized loan process may include various types of guild-levelsmart contracts (or sub-guild-level smart contracts) that are configuredto ensure that guild members that perform a specific task adhere to thestage-level governance as well as guild-level governance set by aspecific guild. For example, the smart contracts associated with thedecentralized loan process may include guild-level authentication smartcontracts that are configured to, inter alia, ensure that an instance ofthe authentication process conforms to an authentication workflow asdefined by a particular authentication guild-level governance (e.g.,watch authentication guild-level governance).

In embodiments, one or more components of the tokenization platform 100supports the securitized, decentralized loan processes. In someembodiments, the tokenization platform 100 may receive requests fromborrowers (or other parties) to initiate an instance of a loan process.In example embodiments, the collateral management system 804 may presenta GUI to a user (e.g., a borrower), whereby the user can requestinitiation of a new loan process via the GUI. For example, the user mayprovide a location or general area, a type of the collateral item (e.g.,a watch, a pair of sneakers, a car, a whiskey collection, jewelry, orthe like), and an approximate loan amount that the borrower wishes tosecure. In some embodiments, the collateral management system 804 mayreceive the request and may instruct the ledger management system 104(or another suitable system) to instantiate a new loan process smartcontract 2022. In embodiments, the loan process smart contract 2022manages a loan process workflow by progressing the loan process throughvarious stages of a decentralized loan process. Alternatively, thecollateral management system 2022 may manage the loan process workflowas the loan process progresses through the stages of the decentralizedloan process. As discussed, a loan process workflow may define a set ofstages that are performed in connection with an instance of adecentralized loan process, where the stages are performed in apredefined order. Different variations of decentralized loan processesmay implement different loan process workflows. An example of a seriesof stages of a loan process workflow may be: a request stage where auser requests a new loan process, followed by an authentication stagewhere the borrower provides the collateral item to be authenticated byone or more authenticators, followed by an appraisal stage (if the itemis deemed authentic) where the item is appraised by one or moreappraisers, followed by a safekeeping stage where the collateral item isstored in escrow by a safekeeper, followed by a tokenization stage wherea VIRL representing the collateral item is generated and the VIRL istokenized, followed by a lending stage where the borrower negotiates theloan with one or more lenders, a repayment stage where the lender paysback the loan or defaults on the loan, and a post-loan stage where thecollateral item may be liquidated if the seller defaulted on at least aportion of the repayment amount, where rewards are issued to variousparticipants of the loan process, and/or analytics are updated based onthe results of the loan process. The foregoing loan process workflow isan example loan process workflow and other loan process workflows aredisclosed and within the scope of the disclosure. It is noted thatdifferent loan process workflows may achieve different efficiencies andmay be better suited for different types of collateral and/or sizes ofloans. The example loan process workflow discussed above is meant tominimize the number of stages that are performed if an item is deemedfake by an authenticator. Other workflows may achieve differentefficiencies, such as lessening the number of times a collateral itemneeds to be transferred between participants, mitigating the need totransfer the collateral item between parties, maximizing the amount of aloan, and/or other desirable efficiencies.

In some embodiments, the collateral management system 804 may select aparticular loan process workflow from a set of loan process workflowsupon receiving a request from a user. In some of these embodiments, thecollateral management system 804 may select a particular loan processworkflow from a set of different loan process workflows based on thelocation of the borrower, the type of collateral, and/or the amount thatthe borrower wishes to secure in a loan. For example, if the collateralitem is large and/or difficult or expensive to transport (e.g., avehicle, a large wine or whiskey collection, a rare painting, or acrystal chandelier) between different participants, the collateralmanagement system 804 may select a loan process workflow that beginswith a safekeeping stage (after the request stage) followed by atokenization stage, such that the safekeeper may take photographs,videos, and/or other supporting data that are used to generate a VIRLthat may be provided to an authenticator and appraiser, rather thanshipping the collateral item between locations. In another example, ifthe item is the type of item that is often counterfeited (e.g., a watch,handbag, or sneakers), the collateral management system 804 may select aloan process where authentication occurs before appraisal and/orsafekeeping, such that the authenticator(s) may determine whether theitem is fake before moving forward with any other stages. It is notedthat some variations of loan process workflows may include additional oralternative stages. For instance, in some embodiments, a loan processworkflow may include a pre-loan liquidation stage where a pre-loanliquidation event is conducted, as is discussed in the disclosure.

In embodiments, the collateral management system 802 and theauthentication system 804 may operate in conjunction with the ledgermanagement system 104 to instantiate or initiate the instantiation of aseries of smart contract instances that are used to manage decentralizedloan process in general (e.g., loan process smart contracts 2022) and/orthe respective stages of the decentralized loan process, such as itemauthentication (e.g., authentication smart contracts 2028), itemappraisal (e.g., appraisal smart contracts 2030), contingencyliquidation events (e.g., liquidation smart contracts), item safekeeping(e.g., safekeeping smart contracts 2032), and/or loangeneration/repayment (e.g., loan smart contracts 2034). In someembodiments, the collateral management system 802 may instantiate a loanprocess smart contract 2022, and the loan process smart contract 2022may in turn instantiate smart contracts that manage one or more stagesof the loan process as the loan process smart contract 2022 determinescertain defined conditions have been met and the loan process progressesthrough the loan process workflow.

In some embodiments, the authentication system 804 may be configured toassign tasks to different participants as the loan process advances todifferent stages. In embodiments, the authentication system 804 may beconfigured to assign tasks to participants during a loan process. Inparticular, the authentication system 804 may be configured to assignauthentication tasks to authenticators, appraisal tasks to appraisers,and/or safekeeping tasks to safekeepers. In embodiments, theauthentication system 804 may select authenticators, appraisers, andsafekeepers based on the contents of the request. For instance, inembodiments where authenticators and appraisers are organized intoguilds that specialize in authenticating or appraising specific types ofitems, the authentication system 804 may determine a respectiveauthentication guild or appraisal guild based on the type of item beingauthenticated and appraised. For instance, if a watch is beingauthenticated and appraised, the authentication system 804 may identifythe watch authentication guild and the watch appraisal guild as therelevant guilds. From the identified guilds, the authentication system804 may select a respective guild member from the identified guilds toperform the authentication task and the appraisal task. To the extentthat safekeepers have specialized and/or regional guilds, as opposed toa single guild comprised of all eligible safekeepers, the authenticationsystem 804 may select a certain safekeeper guild based on type of guild(e.g., automobile safekeepers, safekeepers of perishable items, or thelike) and/or based on a proximity of a particular guild to thecollateral (e.g., Nevada-based safekeeper guild is selected when thecollateral item is located in or near Nevada). Once a guild isidentified to perform a task (assuming a guild needs to be identifiedbefore a task is assigned to a guild member), the authentication system804 may assign one or more members of the guild to perform the task.

In embodiments, the authentication system 804 can implement a number ofdifferent approaches for identifying a guild member to perform a task.In example embodiments, the authentication system 804 may use afirst-in-first-out queue where guild members are assigned to respectivetasks in an order determined by the queue. In example embodiments, theauthentication system 804 may use a round-robin selection scheme toselect a participant. In embodiments, the authentication system 804randomly assigns the authentication and appraisal tasks to a guildmember. In example embodiments, the authentication system 804 may use aweighted selection process where guild members are assigned torespective tasks based on a set of selection criteria, such asrespective bandwidths of the participants that can perform the task(e.g., guild members), a brand or subspecies of the collateral item, theratings of the respective participants, the respective proximities ofthe respective participants to the collateral item, respective amountsof time since a most recent task was assigned to each respectiveparticipant, the number of successful tasks performed by each respectiveparticipant, the number of unsuccessful tasks performed by eachrespective participant, a percentage of successful or unsuccessful tasksperformed by each respective participant, and/or the like. Inembodiments, the authentication system 804 may employ a bidding systemwhere guild members can bid on a task and the guild member is selectedbased on the bid (and/or other selection criteria). In embodiments, thebids may indicate be a price for which the guild member will perform thetask. In these embodiments, the authentication system 804 may select theguild member based on the bid amount and/or selection criteria (e.g.,using a selection model that takes in bid amount as well as any othersuitable selection criteria as factors) or the borrower may select theauthenticator (e.g., the borrower may be presented with the bid amountsas respective fees the borrower would have to pay to a respective bidderand may also be shown their location and ratings and the borrowerselects the bid that makes the most sense to him or her). Alternativelythe bids may indicate the price the guild member is willing to pay toobtain the respective task. In these embodiments, the authenticationsystem 804 may be configured to select the guild member based on thehighest bid. In the scenarios where primary and secondary participantsperform a task (e.g., primary and secondary authenticators andprimary/secondary appraisers), available participants can provide a bidto be the primary participant and/or a bid to be the secondaryparticipant, such that the primary participants and the one or moresecondary participants are selected based on the respective bids and awinner of the right to perform the primary task cannot be the winner ofthe right to perform the secondary task. The authentication system 804may employ any other suitable techniques to select a guild member toperform authentication or appraisal tasks. Once the authenticationsystem 804 has a task to an individual, the authentication system 804may provide a notification to the selected individual and/or theinstance of the loan process smart contract 2022 governing the loanprocess at issue.

For purposes of explanation, the authentication system 804 is describedas assigning tasks to participants, but other suitable components of thetokenization platform 100 may assign tasks to participants.Alternatively, task assignments can be handled “on-chain”, such that oneor more smart contracts may be configured to assign tasks toparticipants. For example, an instance of a loan process smart contract2022 may be configured to assign tasks to participants during theexecution of an instance of a loan process. Additionally oralternatively, instances of stage-level smart contracts may beconfigured to assign tasks to participants upon being instantiatedduring the course of the loan process. In the latter implementations,the stage-level smart contracts may use a combination of selectioncriteria and/or selection schemes to assign tasks. For instance, astage-level smart contract (e.g., an authentication smart contract 2028,an appraisal smart contract 2030, and/or a safekeeping smart contract2032) or a guild-level smart contract (if a guild has a guild-levelsmart contract) can be configured to assign a respective tasks to one ormore participants randomly, in accordance with a queue, via a biddingprocess, in a round-robin manner, and/or according to a set of selectioncriteria. Examples of selection criteria may include the respectivebandwidths of the participants that can perform the task (e.g., guildmembers), the ratings of the respective participants, the respectiveproximities of the respective participants to the collateral item,respective amounts of time since a most recent task was assigned to eachrespective participant, the number of successful tasks performed by eachrespective participant, the number of unsuccessful tasks performed byeach respective participant, a percentage of successful or unsuccessfultasks performed by each respective participant, and/or the like.

In some embodiments, the marketplace system 202 (e.g., item managementsystem 202 (FIG. 2)) is configured to generate virtual representations(VIRLs) of collateral items and the ledger management system 104 (e.g.,the token generation system 302) may be configured to tokenize one ormore VIRLs into a collateral token. It is appreciated that if a borrowerwishes to collateralize more than one item to secure a single loan, theitem management system 202 may generate a set of VIRLs that respectivelycorrespond to the different collateral items, while the ledgermanagement system 102 may individually tokenize the VIRLs intorespective collateral tokens 2042 or may tokenize the set of VIRLs in asingle collateral token 2042 that wraps the set of VIRLs. Examplemethods and systems for generating VIRLs and tokens are discussed ingreater detail with respect to FIGS. 1-4 and elsewhere throughout thedisclosure. Initially, the ledger management system 104 may assign theownership of the collateral token 2042 to the borrower by writingownership data 2054 to the collateral token 2042 to a distributed ledger2019 and/or depositing the collateral token 2042 into an account of theborrower. Even after the borrower has provided the correspondingcollateral item to a safekeeper, the borrower may maintain ownershiprights to the collateral token 2042. Upon the borrower and one or morelenders agreeing to a loan and executing the loan, the collateral token2042 may be “locked” by transferring the collateral token 2042 to anescrow account and updating the ownership data 2054 of the collateraltoken 2042 to indicate that the collateral token 2042 is currently heldin escrow. Once a loan has been repaid (e.g., by the borrower or fromthe proceeds of a post-default liquidation event), a collateral token isunlocked by transferring the collateral token 2042 to an account eitherthe borrower (if the loan was fully repaid) or the buyer of thecollateral token 2042 (if the collateral item was liquidated). Inunlocking a collateral token, the ledger management system 104 or asmart contract (e.g., an instance of a smart loan process smart contract2022 or loan smart contract 3034) may facilitate the transfer of thecollateral token 2042 to the rightful owner post-repayment by updatingthe ownership data 2054 corresponding to the collateral token 2042 in adistributed ledger 2054 with a data block that indicates an account ofthe owner of the collateral token 2042.

In some embodiments, the collateral management system 802 (or any othersuitable component of the tokenization platform) facilitates thenegotiation of a loan agreement between a borrower and lender. Thecollateral management system 802 may be configured to facilitate thenegotiation of loan agreements in any suitable manner. In someembodiments, the collateral management system 802 may provide a GUI to aborrower that allows the borrower to request a loan. Assuming that thecollateral item has been authenticated and appraised (or bought on acontingency), the collateral management system 802 may allow the user torequest a loan amount that does not exceed the appraised value and torequest an amount of time to pay back the loan. In some of theseembodiments, the collateral management system 802 may generate a loanrequest that is presented to potential lenders via a GUI, whereby theloan request indicates the sought amount, the length of the loan, andinformation relating to the collateral item provided by the borrower.The information relating to the collateral item may include the VIRL ofthe collateral item (which may include images, descriptions, videos, andother suitable information), authentication reports, appraisal reports,safekeeping reports, verification that the authentication, appraisal,and safekeepers have secured their respective tasks (as describedabove), and/or the like. In embodiments, the collateral managementsystem 802 may suggest a loan repayment amount and/or an interest rate(e.g., based on current market conditions) for the loan. Alternatively,a potential lender may provide an interest rate or a total repaymentamount that the borrower would have to pay back via the GUI.Additionally, the potential lender may counter one or more of the loanterms, such as the loan amount and/or the repayment period. The loanoffer may then be communicated to a borrower via a GUI, where theborrower may view the loan offer via a borrower device 2002. Inresponse, the borrower may accept the loan offer, reject the loan offer,or provide a counteroffer. The parties may iterate in the manner untilan agreement is reached or one or both parties reject the loan offer.Upon a loan being reached, the parties may execute the loan agreementand the collateral management system 802 may provide a notification tothe loan process smart contract indicating that a loan agreement hasbeen agreed to by the borrower and a lender may provide the details ofthe loan agreement to the smart contract (e.g., in a .JSON file). Inresponse, the loan process smart contract 2022 (or the collateralmanagement system 802) may instantiate a loan smart contract instancethat executes a loan repayment workflow, in the manner described above.It is appreciated that in some embodiments, the loan negotiation may behandled on-chain, such that a smart contract instance (e.g., theinstance of the loan process smart contract 2022 or an instance of aloan smart contract) facilitates the negotiation of the loan agreementin the manner described above. Once a loan is negotiated, the collateraltoken 2042 may be locked in an escrow account and repayment of the loanmay be handled by the loan smart contract instance. If the loan isrepaid in full, the collateral token 2042 may be unlocked and returnedto the borrower, whereby the ownership data 2052 of the token 2042 isupdated to reflect that the borrower is the owner of the collateraltoken 2052 and the borrower may redeem the token 2052 to retakepossession of the collateral item. If the borrower does not successfullyrepay the loan in accordance with the terms of the loan agreement, theloan contract instance may deem the loan in default.

In some embodiments, the default of the loan may trigger a liquidationstage, where the collateral token 2042 is liquidated to cover theremaining balance of the loan. In embodiments, a liquidation stage maybe automatically triggered when a borrower defaults on a loan inaccordance with a loan agreement. In embodiments, a smart contractinstance (e.g., an instance of a loan process smart contract 2022 or aninstance of a loan smart contract 2036) may receive payment eventnotifications indicating payments made by the borrower towards repaymentof the loan. Each time a payment is due, the smart contract instance maydetermine whether a payment was received. If a schedule payment ismissed, the smart contract instance may determine if the borrower is ina default condition. A default condition may not necessarily be themissing of a single payment but may be defined in the loan agreement asmissing a number of consecutive payments or being behind on a certainamount of payments relative to the loan repayment amount. If theborrower is in a default condition, the smart contract instance maytrigger a liquidation event. In some embodiments, the smart contract mayissue a liquidation request to a marketplace (e.g., marketplace system102) that indicates the collateral token 2042 and/or the VIRL wrappedtherein. The liquidation request may include additional data, such as anappraised amount, appraisal records, authentication records, safekeepingrecords, and/or a remaining balance on the loan repayment amount. Inresponse, the marketplace may conduct a liquidation sale. Inembodiments, the liquidation sale may be a fixed price sale (e.g., setat the appraised value) or an auction (e.g., starting at the remainingbalance of the loan repayment amount). Once the item is liquidated, thesmart contract instance may receive a liquidation notification thatindicates that the item was liquidated. In response, the smart contractinstance may initiate the transfer of the collateral token 2042 that wasused to secure the defaulted upon loan from the escrow account in whichit was held to an account of the buyer of the collateral item. Once theownership data 2054 of the collateral token is updated to indicate thatthe collateral token 2042 is owned by the buyer, the buyer may thenredeem the collateral token 2042 (e.g., as described throughout thedisclosure).

Upon taking ownership of a collateral token 2042, an owner of thecollateral token 2042 can redeem the token (e.g., using a GUI thatprovides a mechanism to initiate redemption of a token). Redemption of acollateral token may be handled off-chain by a trusted third party, suchas by the redemption system 404 of the tokenization platform 100 and/oron-chain by an instance of a smart contract corresponding to thecompleted loan transaction, such as the instance of the loan processsmart contract 2022 that managed the loan transaction and/or theinstance of the safekeeping smart contract 2032 that was created whenthe collateral item was deposited with the safekeeper of the collateralitem to ensure that a collateral item is returned to the rightful ownerin a trustless manner, such that the safekeeper can be confident thatthey are returning the collateral item to the rightful owner.

In embodiments, the redemption of a collateral token 2042 may beperformed in accordance with a collateral redemption workflow, which maybe executed off-chain (e.g., by a computing system of a trusted-thirdparty) or on-chain (e.g., by instances of one or more smart contracts).In embodiments, the collateral redemption workflow may include, but isnot limited to, the following operations: receiving a request to redeema collateral item indicated by a collateral token 2042 from a userdevice; verifying the user that is attempting to redeem the collateraltoken 2042 is the rightful owner of the collateral token 2042 based onownership data 2052 stored on a distributed ledger 2016; identifying asafekeeper of the collateral item indicated by the collateral token 2042from the distributed ledger 2016 and/or the loan process smart contract2022; transmitting a redemption notification to a safekeeper device 2008of the identified safekeeper that the rightful owner has redeemed thecollateral token 2042; receiving a confirmation notification from thesafekeeper device 2008 of the identified safekeeper indicating that therightful owner of the collateral token has taken ownership of thecollateral item; and burning the collateral token 2042 in response toreceiving the notification from the safekeeper (as described above). Inembodiments, the redemption workflow may include additional oralternative steps, such as receiving feedback from the redeeming ownerof the collateral item indicating that the collateral item has beenreturned in satisfactory condition and/or updating a distributed ledger2016 to indicate the occurrence and content of such feedback events(which may be used to update analytics and/or a rating of thesafekeeper).

In embodiments, the tokenization platform 100 is configured to performsanalytics on various stages of performed loan processes. In some ofthese embodiments, the analytics and reporting system 112 may beconfigured to obtain event records 2052 and/or supporting data 2056 fromthe set of distributed ledgers 2016 to determine outcomes related to theloan process, including negative outcomes such as false positiveauthentications (e.g., when an item is deemed authentic but later provento be fake), false negative authentications (e.g., when an item isdeemed fake but later proven to be authentic), overvalued appraisals,undervalued appraisals, damaged or lost collateral items duringsafekeeping, loan defaults, or the like. For example, the analytics andreporting system 112 may be configured to determineauthentication-related statistics, such as the percentage of falsepositive authentications were issued by each guild and/or guild members.In this example, the analytics and reporting system 112 may read anyevent records 2052 associated with liquidated items that were deemedauthentic by a guild or guild member and later reported to be fake bythe purchaser (which may be referred to as “false positives) against thetotal number of authentications that were performed by a guild or guildmember. In another example, the analytics and reporting system 112 mayidentify instances where authentication tasks resulted in undervalued orovervalued appraised values. In this example, analytics and reportingsystem 112 may determine a number of event records 2052 associated withliquidated items that were sold below (overvalued by a certainpercentage from the liquidation value) or above (undervalued by acertain percentage from the liquidation value) the appraised valueprovided by the appraiser in relation to the number of all appraisalsand/or successful appraisals (e.g., within a certain percentage of theliquidation value). These types of statistical insights may then be usedto identify common features of tasks that result in negative outcomes(e.g., false positive cases, false negative cases, undervaluation cases,overvaluation cases, and/or lost or damaged collateral cases) that arenot shared with successful cases and in some instances may adjust thestage-level governance to mitigate those features.

In another example, the analytics and reporting system 112 may determineturnover time by task performers (e.g., authenticators and/orappraisers). In this example, the analytics and reporting system 112 mayobtain various event records 2052 associated with certain portions ofloan processes, such as event records 2052 that indicate when tasks wereassigned to particular participants with a loan process and eventrecords 2052 that indicate when those participants finished the task.The analytics and reporting system 112 may then determine a time tocomplete each instance of the task and may determine various analyticalinsights such as average turnover time for individual guild members,average turnaround times for a particular task for an entire guild orsub-guild, average turnaround times across all stage participants,average turnaround times for particular types of collateral items orsubspecies of collateral items, and the like. These insights may be usedto set time constraints on tasks in future governances, such that theparticipants reward may be lessened if the time constraints are not met.

In embodiments, the analytics and reporting system 112 may be configuredto provide ratings to different participants in the loan processecosystem 2000, such as borrowers, authenticators, appraisers,safekeepers, and/or lenders. In embodiments, the analytics and reportingsystem 112 may determine negative and positive outcomes associated withthe various different participants, such as successful repayments v.default events by borrowers, false negatives/false positives v.successful authentications by authenticators, under-valuations and/orovervaluations by appraisers v. successful appraisals by appraisers,instances of damaged or lost collateral items v. successful safekeepingtasks by safekeepers, and the like. The analytics and reporting system112 may collect additional or alternative data relating to participants,such as feedback of other participants. The analytics and reportingsystem 112 may then apply a scoring function to the outcome and otherfeedback data related to participants to assign scores to theparticipants. These scores may be relevant when assigning tasks,awarding guild tokens, rewarding participants, and/or the like.

In embodiments, the analytics and reporting system 112 may obtain datafrom the distributed ledgers. In some of these embodiments, a nodedevice 2014 may be configured as a “history node” that monitors all datablocks being written to the distributed ledgers 2016. The history nodedevice may process and index each block as it is being written to theledger 2016 and may provide this information to the analytics andreporting system 112. The analytics and reporting system 112 may thenperform its analytics on the data collected by the history node. Theanalytics and reporting system 112 may collect data from the distributedledger 2016 in other suitable manners without departing from the scopeof the disclosure.

FIG. 27 illustrates an example of loan process workflow 2700 accordingto some embodiments of the present disclosure. In the example of FIG.27, the loan process workflow may be performed for collateral items thatare easily counterfeited, such as watches, jewelry, handbags, sneakers,or the like. In the example of FIG. 27, the loan process workflow 2700may include: a request stage 2702 where the borrower requests to begin aloan process; followed by an authentication stage 2704 where one or moreauthenticators authenticate the one or more items; followed by anappraisal stage 2706 where the authenticated items are appraised;followed by a safekeeping stage 2708 where the appraised items arestored in escrow with a trusted safekeeper; followed by a tokenizationstage 2710 where the ledger management system 104 (or another suitablecomponent) generates VIRLs of the one or more escrowed items andgenerates a collateral token by tokenizing the VIRLs of the escroweditems; followed by a lending stage 2712 where a loan is negotiated andaccepted by the borrower and a lender; followed by a repayment stage2714 where the loan is repaid by the borrower; and followed by apost-loan stage 2716 where the collateral token is unlocked and returnedto the borrower or liquidated if the borrower defaults on the loan andany rewards are issued to the participants of the loan process.

During the request stage 2702, a borrower may request to begin a newloan process that includes collateralizing an item owned by theborrower. In embodiments, the borrower may request the loan via aborrower device 2002 that interfaces with the tokenization platform 100.In these embodiments, the tokenization platform 100 (or another suitablesystem) may provide a GUI where the borrower may provide informationsuch as a collateral item to be collateralized, a location of thecollateral item, a loan amount sought, and/or a proposed loan term. Inresponse to the borrower request, the tokenization platform 100 mayinstantiate a loan process smart contract instance. In embodiments, theloan process smart contract instance may determine a type of thecollateral item (e.g., from the request provided by the borrower) andmay request an authenticator (and potentially secondary authenticators)to authenticate the collateral item, thereby progressing the loanprocess to the authentication stage 2704.

During the authentication stage 2704, the loan process smart contractinstance may instantiate an instance of an authentication smart contract2028. In embodiments, the tokenization platform 100 may assign anauthentication task to a primary authenticator (and potentiallysecondary authenticators) from an authentication guild that specializesin authenticating items such as the collateral item, as described above.In embodiments, the primary authenticator may confirm receipt of theitem to be authenticated via an authenticator device 2004. Inembodiments, the authenticator may generate an authentication reportindicating a determination to the authenticity of the collateral item,as well as any supporting documentation. In embodiments, theauthentication report and supporting evidence may be provided to one ormore secondary authenticators, who in turn may validate theauthentication report and may provide additional supportingdocumentation. In embodiments, the authentication report and anysupporting documentation may be written to a distributed ledger 2016. Insome embodiments, the authenticators that participated in theauthentication task may be required to stake an amount ofcurrency/tokenized tokens as a safeguard in case the item is liquidatedand later deemed fake. In example embodiments, the loan process smartcontract 2022 may include a listening thread that listens for anauthentication notification issued by the instantiated authenticationsmart contract 2028 indicating whether the item was authentic or deemedfake by the authenticator(s), where the notification from theauthentication smart contract 2028 may include the opinion of theauthenticators (e.g., fake or authentic), a hash value of theauthentication report and any other supporting evidence, and/or a blockaddress to the authentication report and the supporting evidence. If theloan process smart contract instance determines that the item was deemedauthentic, the loan process smart contract instance may advance the loanprocess to an appraisal stage 2706.

During the appraisal stage 2706, the loan process smart contractinstance may request one or more appraisers to appraise theauthenticated item and may instantiate an instance of an appraisal smartcontract 2030. In embodiments, the tokenization platform 100 mayidentify one or more appraisers to perform the task based on the type ofcollateral item, as discussed above. In embodiments, a primary appraisermay receive the collateral item (e.g., via mail or other shipping)and/or may receive a VIRL of the collateral item. Knowing that the itemwas deemed authentic by the authenticators, the appraiser may determinean appraised value of the collateral item and may generate an appraisalreport that indicates the appraised value and any supportingdocumentation to support the appraised value. In some embodiments, oneor more secondary appraisers may validate the appraisal report and mayprovide supporting documentation for their respective validations. Inembodiments, the appraisal report and any supporting documentation maybe written to a distributed ledger 2016. In some embodiments, theappraisers that participated in the appraisal task may be required tostake an amount of currency/tokenized tokens equal or proportionate tothe appraised value of the collateral item as a safeguard in case theitem is liquidated at a price that is significantly less than theremaining balance on the repayment amount and/or the appraised value. Inembodiments, the appraisal smart contract 2030 may send a notificationto the loan process smart contract 2022 indicating that an appraisalworkflow was successfully completed, where the notification may includean appraised value, a hash value of the appraisal report and any othersupporting evidence, and/or a block address to the appraisal report andthe supporting evidence. Upon determining that the appraisal stage iscomplete, the loan process smart contract 2022 may advance the loanprocess to the safekeeping stage 2708.

During the safekeeping stage 2708, the loan process smart contractinstance may request a safekeeper to safekeep the appraised item and mayinstantiate an instance of a safekeeping smart contract 2032, whichexecutes a safekeeping workflow. In embodiments, the tokenizationplatform 100 may assign a safekeeper to the safekeeping task, forexample, based on the type of collateral item and/or the safekeeper'sproximity to the collateral item. Once the safekeeper has confirmedreceipt of the item, the safekeeper may generate a safekeeping reportthat indicates that the item is stored and notes any damage to thecollateral item at the time it was received and inspected, as well asany supporting documentation that supports the safekeeping report. Inembodiments, the safekeeping report and any supporting documentation maybe written to a distributed ledger 2016. In some embodiments, thesafekeeper may be required to stake an amount of currency/tokenizedtokens equal or proportionate to the appraised value of the collateralitem as a safeguard in case the item is lost or damaged duringsafekeeping (or may provide proof of insurance). In embodiments, thesafekeeping smart contract instance may then provide a notification tothe loan process smart contract instance indicating that the item hasbeen safely stored in escrow, where the notification may include a hashvalue of the safekeeping report and any other supporting evidence and/ora block address to the safekeeping report and the supporting evidence.In response to the notification, the loan process smart contract mayadvance the loan process to a tokenization stage 2710.

During the tokenization stage 2710, the tokenization platform 100 (oranother suitable component) may generate tokenize the collateral item.In embodiments, the tokenization platform 100 may generate a VIRL of thecollateral item based on data that describes and/or depicts thecollateral item, such as descriptions, images, videos, 2D scans, and/or3D scans of the collateral item. In embodiments, the borrower, thesafekeeper, and/or the authenticator may provide the data used togenerate the VIRL. In embodiments, the tokenization platform 100generates a collateral token of the item based on the VIRL of thecollateral item. Once an item is tokenized, the tokenization platform100 may write the token to the distributed ledger 2016 and may initiallyassign the ownership rights to the collateral token to the borrower(until a loan agreement is reached). Once the collateral item has beentokenized, the tokenization platform 100 may provide a notification tothe loan process smart contract 2022 indicating the tokenization eventand/or an address of the collateral token. Upon receiving notificationof tokenization event, the loan process smart contract 2022 may advancethe loan process to a lending stage 2712.

During the lending stage 2712, the borrower may request a loan and/ormay negotiate a loan with one or more lenders. Upon receivingconfirmation that the lender and borrower have agreed to loan terms, theloan process smart contract 2022 may instantiate a loan smart contract2034 in accordance with the agreed upon terms of the loan. In someembodiments, the tokenization platform 100 may provide a GUI to aborrower that allows the borrower to request a loan from one or morepotential lenders and/or negotiate a loan agreement with the one or morelenders. It is appreciated that in some embodiments, the loannegotiation may be handled on-chain rather than via a centralizedservice, such as the tokenization platform 100. In embodiments, theborrower may request a loan amount that does not exceed the appraisedvalue and a proposed loan term that indicates an amount of time to payback the loan. In some of these embodiments, the tokenization platform100 may generate a loan request that is presented to potential lendersvia a GUI, whereby the loan request indicates the sought amount, thelength of the loan, and information relating to the collateral itemprovided by the borrower (e.g., a VIRL of the collateral item,authentication reports, appraisal reports, safekeeping reports,verification that the authentication, appraisal, and safekeepers havesecured their respective tasks (as described above), and/or the like).In embodiments, the tokenization system 100 may suggest a loan repaymentamount and/or an interest rate (e.g., based on current marketconditions) for the loan. Alternatively, a potential lender may providean interest rate or a total repayment amount that the borrower wouldhave to pay back via the GUI. Additionally, the potential lender maycounter one or more of the requested loan terms, such as the loan amountand/or the repayment period. The loan offer may then be communicated toa borrower via a GUI, where the borrower may view the loan offer via aborrower device 2002. In response, the borrower may accept the loanoffer, reject the loan offer, or provide a counteroffer. The parties mayiterate in the manner until an agreement is reached or one or bothparties reject the loan offer. Upon a loan being reached, the partiesmay execute the loan agreement and the tokenization platform 100 mayprovide a notification to the loan process smart contract instanceindicating that a loan agreement has been agreed to by the borrower anda lender. In embodiments, the notification may include the details ofthe loan agreement including the terms of the loan agreement. Inresponse, the loan process smart contract instance may instantiate aloan smart contract instance that executes a loan repayment workflow.Once a loan agreement is executed, the loan smart contract may lock thecollateral token in an escrow account and may facilitate the transfer ofthe funds from an account of the lender to an account of the borrower.In embodiments, the loan agreement, records of any offers/counteroffers,and records relating to the escrowing of the collateral token and thetransfer funds to the borrower may be written to a distributed ledger2016. Once the loan process smart contract instance receivesnotification that the collateral token has been locked and the fundshave been transferred, the loan process smart contract instance mayadvance the loan process to the repayment stage 2714.

During the repayment stage 2714, the loan smart contract instance maymonitor the borrowers payment history to ensure that payments are madeby the borrower to the lender (or an account that distributes paymentsto the lender) in accordance with a loan schedule and that the loan isnot in a default condition. During the loan repayment stage, theborrower may remit payments. Each time a payment is made, the loanprocess smart contract instance may receive a payment notificationindicating that a payment has been made and an amount of the payment.The loan smart contract instance may then determine whether the loan hasbeen repaid in full. If the loan has not been paid in full, the loansmart contract instance may adjust the loan repayment amount and mayperform additional operations, such as returning some of the stakedfunds from the authenticators, appraisers, and/or safekeepers to reflectthe new loan repayment amount. If the loan smart contract instancedetermines that the loan repayment amount has been paid in full, theloan smart contract instance may send a repayment notification to theloan process smart contract instance indicating that the loan has beenpaid in full and may advance the loan process to the post-loan stage2716. In embodiments, the repayment notification may include hash valuesof payment event records indicating that payments were made and theamount of the payments and/or addresses of the payment records on thedistributed ledger 2016. Conversely, if the loan smart contract instancedetermines that the borrower defaulted, the loan smart contract instancemay trigger a liquidation event and/or send a default notification tothe loan process smart contract indicating that the loan is in defaultin accordance with the terms of the loan. In embodiments the defaultnotification may include hash values of a default event recordindicating which payments were missed and the remaining balance on theloan and/or addresses of the default event record on the distributedledger 2016. In response to receiving a default notification, the loansmart contract instance may initiate a liquation event and may advancethe loan process to the post-loan stage 2716.

During the post-loan stage 2716, the collateral token is either returnedto the owner if the loan has been fully paid or a liquidation event isconducted. In response to receiving a repayment notification that theloan has been repaid in full, the loan smart contract instance mayinitiate the transfer of the collateral token from the escrow account toan account of the borrower, who may then redeem the collateral token toobtain possession of the collateral item. Once the loan has beensuccessfully repaid, the loan process smart contract instance mayinitiate the awarding of rewards to accounts of the authenticator,appraiser, and safekeeper (e.g., from the funds that were paid back tothe lender) in accordance with the terms set forth in the authenticationsmart contract, the appraisal smart contract, and the safekeepingcontract.

In initiating a liquidation event, the loan smart contract instance maysend an address of the collateral token to an appropriate marketplace(e.g., marketplace system 102), which may liquidate the collateral item(e.g., in an auction). During the liquidation event, a buyer maypurchase the collateral token, which results in the ownership data 2054of the collateral token being assigned to the buyer, who may then redeemthe collateral token to obtain possession of the collateral item. Onceliquidated, the loan process smart contract instance may distribute theremainder of the outstanding balance to the lender (or a secondarylender if the loan was sold to a secondary lender) from the proceeds ofthe liquidation event. After the liquidation event, the loan processsmart contract instance may initiate the awarding of rewards to accountsof the authenticators, appraisers, and safekeeper from the proceeds ofthe liquidation event in accordance with the terms set forth in theauthentication smart contract, the appraisal smart contract, and thesafekeeping contract. To the extent any balance remains, the remaindermay be credited to the account of the borrower.

Once the loan process is complete, the loan process smart contractinstance may notify the tokenization platform 100 that the loan processhas been completed, and the tokenization platform 100 may run ananalytics processes based on the completed loan process. In someembodiments, the results of the loan process may be used to update theratings of one or more of the authenticators, the appraisers, thesafekeeper, the lender, and/or the borrower.

It is appreciated that the foregoing is an example of a decentralizedloan process workflow 2700 and that alternative workflows may beexecuted. Furthermore, the decentralized loan process workflow 2700 mayinclude additional or alternative steps that were not explicitlydiscussed.

FIG. 28 illustrates an example of loan process workflow 2800 accordingto some embodiments of the present disclosure. In the example of FIG.28, the loan process workflow 2800 may be performed for collateral itemsthat are not easily shipped and/or are very large, such as vehicles,works of art, delicate objects (e.g., vases or chandeliers), wine orwhiskey collections, and the like. In the workflow 2800 of FIG. 28, thecollateral item is deposited with a safekeeper, who in turn can generatethe VIRL that is tokenized into a collateral token. The VIRL of thecollateral item may then be provided to the authenticators andappraisers without having to transport the physical collateral itembetween parties. In the example of FIG. 28, the loan process workflow2800 may include a request stage 2802 where the borrower requests tobegin a loan process; followed by a safekeeping stage 2804 wherepossession of the collateral item is taken by the safekeeper; followedby a tokenization stage 2806 where the safekeeper may provide therequisite documentation to generate a VIRL of the collateral item istokenized into a collateral token; followed by an authentication stage2808 where one or more authenticators authenticate the one or moreitems; followed by an appraisal stage 2810 where the authenticated itemsare appraised; followed by a lending stage 2812 where a loan isnegotiated and accepted by the borrower and a lender; followed by arepayment stage 2814 where the loan is repaid by the borrower; andfollowed by a post-loan stage 2816 where the collateral token isunlocked and returned to the borrower or liquidated if the borrowerdefaults on the loan and any rewards are issued to the participants ofthe loan process.

During the request stage 2802, a borrower may request to begin a newloan process that includes collateralizing an item owned by theborrower. In embodiments, the borrower may request the loan via aborrower device 2002 that interfaces with the tokenization platform 100.In these embodiments, the tokenization platform 100 (or another suitablesystem) may provide a GUI where the borrower may provide informationsuch as a collateral item to be collateralized, a location of thecollateral item, a loan amount sought, and/or a proposed loan term. Inresponse to the borrower request, the tokenization platform 100 mayinstantiate a loan process smart contract instance. In embodiments, theloan process smart contract instance may determine a type of thecollateral item (e.g., from the request provided by the borrower) andmay request a safekeeper to safekeep the collateral item in escrowduring the loan process, thereby progressing the loan process to thesafekeeping stage 2804.

During the safekeeping stage 2804, the loan process smart contractinstance may request a safekeeper to safekeep the collateral item andmay instantiate an instance of a safekeeping smart contract 2032, whichexecutes a safekeeping workflow. In embodiments, the tokenizationplatform 100 may assign a safekeeper to the safekeeping task, forexample, based on the type of collateral item and/or the safekeeper'sproximity to the collateral item. Once the safekeeper has confirmedreceipt of the item, the safekeeper may generate a safekeeping reportthat indicates that the item is stored and notes any damage to thecollateral item at the time it was received and inspected, as well asany supporting documentation that supports the safekeeping report. Inembodiments, the safekeeping report and any supporting documentation maybe written to a distributed ledger 2016. In some embodiments, thesafekeeper may be required to stake an amount of currency/tokenizedtokens equal or proportionate to an approximate value of the collateralitem as a safeguard in case the item is lost or damaged duringsafekeeping (or may provide proof of insurance). In embodiments, thesafekeeping smart contract instance may then provide a notification tothe loan process smart contract instance indicating that the item hasbeen safely stored in escrow, where the notification may include a hashvalue of the safekeeping report and any other supporting evidence and/ora block address to the safekeeping report and the supporting evidence.In response to the notification, the loan process smart contract mayadvance the loan process to a tokenization stage 2806.

During the tokenization stage 2806, the tokenization platform 100 (oranother suitable component) may generate tokenize the collateral item.In embodiments, the tokenization platform 100 may generate a VIRL of thecollateral item based on data that describes and/or depicts thecollateral item, such as descriptions, images, videos, 2D scans, and/or3D scans of the collateral item. In embodiments, the borrower or thesafekeeper may provide the data used to generate the VIRL. Inembodiments, the tokenization platform 100 generates a collateral tokenof the item based on the VIRL of the collateral item. Once an item istokenized, the tokenization platform 100 may write the token to thedistributed ledger 2016 and may initially assign the ownership rights tothe collateral token to the borrower (until a loan agreement isreached). Once the collateral item has been tokenized, the tokenizationplatform 100 may provide a notification to the loan process smartcontract 2022 indicating the tokenization event and/or an address of thecollateral token. Upon receiving notification of tokenization event, theloan process smart contract 2022 may advance the loan process to anauthentication stage 2808.

During the authentication stage 2808, the loan process smart contractinstance may instantiate an instance of an authentication smart contract2028. In embodiments, the tokenization platform 100 may assign anauthentication task to a primary authenticator (and potentiallysecondary authenticators) from an authentication guild that specializesin authenticating items such as the collateral item, as described above.In embodiments, the primary authenticator may be sent the VIRL of theitem to be authenticated and the authenticator may generate anauthentication report indicating a determination to the authenticity ofthe collateral item, as well as any supporting documentation. Inembodiments, the authentication report and supporting evidence may beprovided to one or more secondary authenticators, who in turn mayvalidate the authentication report and may provide additional supportingdocumentation. In embodiments, the authentication report and anysupporting documentation may be written to a distributed ledger 2016. Insome embodiments, the authenticators that participated in theauthentication task may be required to stake an amount ofcurrency/tokenized tokens as a safeguard in case the item is liquidatedand later deemed fake. In example embodiments, the loan process smartcontract 2022 may include a listening thread that listen for anauthentication notification issued by the instantiated authenticationsmart contract 2028 indicating whether the item was authentic or deemedfake by the authenticator(s), where the authentication notification fromthe authentication smart contract 2028 may include the opinion of theauthenticators (e.g., fake or authentic), a hash value of theauthentication report and any other supporting evidence, and/or a blockaddress to the authentication report and the supporting documentation.If the loan process smart contract instance determines that the item wasdeemed authentic, the loan process smart contract instance may advancethe loan process to an appraisal stage 2810.

During the appraisal stage 2810, the loan process smart contractinstance may request one or more appraisers to appraise theauthenticated item and may instantiate an instance of an appraisal smartcontract 2030. In embodiments, the tokenization platform 100 mayidentify one or more appraisers to perform the task based on the type ofcollateral item, as discussed above. In embodiments, a primary appraisermay be sent the VIRL of the collateral item. Knowing that the item wasdeemed authentic, the appraiser may determine an appraised value of thecollateral item and may generate an appraisal report that indicates theappraised value and any supporting documentation to support theappraised value. In some embodiments, one or more secondary appraisersmay validate the appraisal report and may provide supportingdocumentation for their respective validations. In embodiments, theappraisal report and any supporting documentation may be written to adistributed ledger 2016. In some embodiments, the appraisers thatparticipated in the appraisal task may be required to stake an amount ofcurrency/tokenized tokens equal or proportionate to the appraised valueof the collateral item as a safeguard in case the item is liquidated ata price that is significantly less than the remaining balance on therepayment amount and/or the appraised value. In embodiments, theappraisal smart contract 2030 may send a notification to the loanprocess smart contract 2022 indicating that an appraisal workflow wassuccessfully completed, where the notification may include an appraisedvalue, a hash value of the appraisal report and any other supportingevidence, and/or a block address to the appraisal report and thesupporting evidence. Upon determining that the appraisal stage iscomplete, the loan process smart contract 2022 may advance the loanprocess to the lending stage 2812.

During the lending stage 2812, the borrower may request a loan and/ormay negotiate a loan with one or more lenders. Upon receivingconfirmation that the lender and borrower have agreed to loan terms, theloan process smart contract 2022 may instantiate a loan smart contract2034 in accordance with the agreed upon terms of the loan. In someembodiments, the tokenization platform 100 may provide a GUI to aborrower that allows the borrower to request a loan from one or morepotential lenders and/or negotiate a loan agreement with the one or morelenders. It is appreciated that in some embodiments, the loannegotiation may be handled on-chain rather than via a centralizedservice, such as the tokenization platform 100. In embodiments, theborrower may request a loan amount that does not exceed the appraisedvalue and a proposed loan term that indicates an amount of time to payback the loan. In some of these embodiments, the tokenization platform100 may generate a loan request that is presented to potential lendersvia a GUI, whereby the loan request indicates the sought amount, thelength of the loan, and information relating to the collateral itemprovided by the borrower (e.g., a VIRL of the collateral item,authentication reports, appraisal reports, safekeeping reports,verification that the authentication, appraisal, and safekeepers havesecured their respective tasks (as described above), and/or the like. Inembodiments, the tokenization system 100 may suggest a loan repaymentamount and/or an interest rate (e.g., based on current marketconditions) for the loan. Alternatively, a potential lender may providean interest rate or a total repayment amount that the borrower wouldhave to pay back via the GUI. Additionally, the potential lender maycounter one or more of the requested loan terms, such as the loan amountand/or the repayment period. The loan offer may then be communicated toa borrower via a GUI, where the borrower may view the loan offer via aborrower device 2002. In response, the borrower may accept the loanoffer, reject the loan offer, or provide a counteroffer. The parties mayiterate in the manner until an agreement is reached or one or bothparties reject the loan offer. Upon a loan being reached, the partiesmay execute the loan agreement and the tokenization platform 100 mayprovide a notification to the loan process smart contract instanceindicating that a loan agreement has been agreed to by the borrower anda lender. In embodiments, the notification may include the details ofthe loan agreement including the terms of the loan agreement. Inresponse, the loan process smart contract instance may instantiate aloan smart contract instance that executes a loan repayment workflow.Once a loan agreement is executed, the loan smart contract may lock thecollateral token in an escrow account and may facilitate the transfer ofthe funds from an account of the lender to an account of the borrower.In embodiments, the loan agreement, records of any offers/counteroffers,and records relating to the escrowing of the collateral token and thetransfer funds to the borrower may be written to a distributed ledger2016. Once the loan process smart contract instance receivesnotification that the collateral token has been locked and the fundshave been transferred, the loan process smart contract instance mayadvance the loan process to the repayment stage 2814.

During the repayment stage 2814, the loan smart contract instance maymonitor the borrowers payment history to ensure that payments are madeby the borrower to the lender (or an account that distributes paymentsto the lender) in accordance with a loan schedule and that the loan isnot in a default condition. During the loan repayment stage, theborrower may remit payments. Each time a payment is made, the loanprocess smart contract instance may receive a payment notificationindicating that a payment has been made and an amount of the payment.The loan smart contract instance may then determine whether the loan hasbeen repaid in full. If the loan has not been paid in full, the loansmart contract instance may adjust the loan repayment amount and mayperform additional operations, such as returning some of the stakedfunds from the authenticators, appraisers, and/or safekeepers to reflectthe new loan repayment amount. If the loan smart contract instancedetermines that the loan repayment amount has been paid in full, theloan smart contract instance may send a repayment notification to theloan process smart contract instance indicating that the loan has beenpaid in full and may advance the loan process to the post-loan stage2816. In embodiments, the repayment notification may include hash valuesof payment event records indicating that payments were made and theamount of the payments and/or addresses of the payment records on thedistributed ledger 2016. Conversely, if the loan smart contract instancedetermines that the borrower defaulted, the loan smart contract mayinstance may trigger a liquidation event and/or send a defaultnotification to the loan process smart contract indicating that the loanis in default in accordance with the terms of the loan. In embodimentsthe default notification may include hash values of a default eventrecord indicating which payments were missed and the remaining balanceon the loan and/or addresses of the default event record on thedistributed ledger 2016. In response to receiving a defaultnotification, the loan smart contract instance may initiate a liquationevent and may advance the loan process to the post-loan stage 2816.

During the post-loan stage 2816, the collateral token is either returnedto the owner if the loan has been fully paid or a liquidation event isconducted. In response to receiving a repayment notification that theloan has been repaid in full, the loan smart contract instance mayinitiate the transfer of the collateral token from the escrow account toan account of the borrower, who may then redeem the collateral token toobtain possession of the collateral item. Once the loan has beensuccessfully repaid, the loan process smart contract instance mayinitiate the awarding of rewards to accounts of the authenticator,appraiser, and safekeeper (e.g., from the funds that were paid back tothe lender) in accordance with the terms set forth in the authenticationsmart contract, the appraisal smart contract, and the safekeepingcontract.

In initiating a liquidation event, the loan smart contract instance maysend an address of the collateral token to an appropriate marketplace(e.g., marketplace system 102), which may liquidate the collateral item(e.g., in an auction). During the liquidation event, a buyer maypurchase the collateral token, which results in the ownership data 2054of the collateral token being assigned to the buyer, who may then redeemthe collateral token to obtain possession of the collateral item. Onceliquidated, the loan process smart contract instance may distribute theremainder of the outstanding balance to the lender (or a secondarylender if the loan was sold to a secondary lender) from the proceeds ofthe liquidation event. After the liquidation event, the loan processsmart contract instance may initiate the awarding of rewards to accountsof the authenticators, appraisers, and safekeeper from the proceeds ofthe liquidation event in accordance with the terms set forth in theauthentication smart contract, the appraisal smart contract, and thesafekeeping contract. To the extent any balance remains, the remaindermay be credited to the account of the borrower.

Once the loan process is complete, the loan process smart contractinstance may notify the tokenization platform 100 that the loan processhas been completed, and the tokenization platform 100 may run ananalytics processes based on the completed loan process. In someembodiments, the results of the loan process may be used to update theratings of one or more of the authenticators, the appraisers, thesafekeeper, the lender, and/or the borrower.

It is appreciated that the foregoing is an example of a decentralizedloan process workflow 2800 and that alternative workflows may beexecuted. Furthermore, the decentralized loan process workflow 2800 mayinclude additional or alternative steps that were not explicitlydiscussed.

FIG. 29 illustrates an example of loan process workflow 2900 accordingto some embodiments of the present disclosure. In the example of FIG.29, the loan process workflow 2900 may be performed when a borrower islikely overvaluing the collateral item. For example, the borrower maywish to secure a loan amount that is equal to $10,000 and wants tosecure the loan with a pair of designer sneakers. In this situation, theloan process workflow 2900 of FIG. 29 may be executed, with theappraisal stage being performed before the authentication stage andsafekeeping stage. In this way, if the appraised value is much less thanthe desired loan amount, the borrower may elect to forego the loanprocess without having to pay an authentication fee and/or a safekeepingfee. In the example of FIG. 29, the loan process workflow 2900 mayinclude: a request stage 2902 where the borrower requests to begin aloan process; followed by an appraisal stage 2904 where one or moreappraisers appraise the one or more items; followed by an authenticationstage 2906 where the appraised items are authenticated; followed by asafekeeping stage 2908 where the authenticated items are stored inescrow with a trusted safekeeper; followed by a tokenization stage 2910where the ledger management system 104 (or another suitable component)generates VIRLs of the one or more escrowed items, generates acollateral token by tokenizing the VIRLs of the escrowed items; followedby a lending stage 2912 where a loan is negotiated and accepted by theborrower and a lender; followed by a repayment stage 2914 where the loanis repaid by the borrower; and followed by a post-loan stage 2916 wherethe collateral token is unlocked and returned to the borrower orliquidated if the borrower defaults on the loan and any rewards areissued to the participants of the loan process.

During the request stage 2902, a borrower may request to begin a newloan process that includes collateralizing an item owned by theborrower. In embodiments, the borrower may request the loan via aborrower device 2002 that interfaces with the tokenization platform 100.In these embodiments, the tokenization platform 100 (or another suitablesystem) may provide a GUI where the borrower may provide informationsuch as a collateral item to be collateralized, a location of thecollateral item, a loan amount sought, and/or a proposed loan term. Inresponse to the borrower request, the tokenization platform 100 mayinstantiate a loan process smart contract instance. In embodiments, theloan process smart contract instance may determine a type of thecollateral item (e.g., from the request provided by the borrower) andmay request an appraiser (and potentially secondary appraisers) toappraise the collateral item, thereby progressing the loan process tothe appraisal stage 2904.

During the appraisal stage 2904, the loan process smart contractinstance may instantiate an instance of an appraisal smart contract 2030and may request one or more appraisers to appraise the authenticated. Inembodiments, the tokenization platform 100 may identify one or moreappraisers to perform the task based on the type of collateral item, thelocation of the item, and/or the like, as was discussed above. Inembodiments, a primary appraiser may receive the collateral item (e.g.,via mail or other shipping) and may determine an appraised value of thecollateral item. In this workflow 2900, the appraiser does not have thebenefit of knowing that the item was deemed authentic by theauthenticators. Nevertheless, the appraiser may assume that the itemwill be deemed authentic by the authenticators. In embodiments, theprimary appraiser may generate an appraisal report that indicates thedetermined appraised value and any supporting documentation to supportthe appraised value. In some embodiments, one or more secondaryappraisers may validate the appraisal report and may provide supportingdocumentation for their respective validations. In embodiments, theappraisal report and any supporting documentation may be written to adistributed ledger 2016. In some embodiments, the appraisers thatparticipated in the appraisal task may be required to stake an amount ofcurrency/tokenized tokens equal or proportionate to the appraised valueof the collateral item as a safeguard in case the item is liquidated ata price that is significantly less than the remaining balance on therepayment amount and/or the appraised value. In embodiments, theappraisal smart contract 2030 may send a notification to the loanprocess smart contract 2022 indicating that an appraisal workflow wassuccessfully completed, where the notification may include an appraisedvalue, a hash value of the appraisal report and any other supportingevidence, and/or a block address to the appraisal report and thesupporting evidence. In some scenarios, the appraised value will be muchless than the requested loan amount, in which case, the borrower may optto end the loan process. Assuming the borrower decides to continue theloan process given the appraised value, the loan process smart contract2022 may advance the loan process to the appraisal stage 2906.

During the authentication stage 2906, the loan process smart contractinstance may instantiate an instance of an authentication smart contract2028. In embodiments, the tokenization platform 100 may assign anauthentication task to a primary authenticator (and potentiallysecondary authenticators) from an authentication guild that specializesin authenticating items such as the collateral item, as described above.In embodiments, either the collateral item is physically sent to theprimary authenticator (e.g., from the appraiser) or a VIRL of thecollateral item is digitally sent to authenticator. In embodiments, theprimary authenticator may confirm receipt of the collateral item to beauthenticated (or a VIRL thereof) via an authenticator device 2004. Inembodiments, the authenticator may generate an authentication reportindicating a determination to the authenticity of the collateral item,as well as any supporting documentation. In embodiments, theauthentication report and supporting evidence may be provided to one ormore secondary authenticators, who in turn may validate theauthentication report and may provide additional supportingdocumentation. In embodiments, the authentication report and anysupporting documentation may be written to a distributed ledger 2016. Insome embodiments, the authenticators that participated in theauthentication task may be required to stake an amount ofcurrency/tokenized tokens as a safeguard in case the item is liquidatedand later deemed fake. In example embodiments, the loan process smartcontract 2022 may include a listening thread that listen for anauthentication notification issued by the instantiated authenticationsmart contract 2028 indicating whether the item was authentic or deemedfake by the authenticator(s), where the notification from theauthentication smart contract 2028 may include the opinion of theauthenticators (e.g., fake or authentic), a hash value of theauthentication report and any other supporting evidence, and/or a blockaddress to the authentication report and the supporting evidence. If theloan process smart contract instance determines that the item was deemedauthentic, the loan process smart contract instance may advance the loanprocess to a safekeeping stage 2908.

During the safekeeping stage 2908, the loan process smart contractinstance may request a safekeeper to safekeep the collateral item andmay instantiate an instance of a safekeeping smart contract 2032, whichexecutes a safekeeping workflow. In embodiments, the tokenizationplatform 100 may assign a safekeeper to the safekeeping task, forexample, based on the type of collateral item and/or the safekeeper'sproximity to the collateral item. Once the safekeeper has confirmedreceipt of the item, the safekeeper may generate a safekeeping reportthat indicates that the item is stored and notes any damage to thecollateral item at the time it was received and inspected, as well asany supporting documentation that supports the safekeeping report. Inembodiments, the safekeeping report and any supporting documentation maybe written to a distributed ledger 2016. In some embodiments, thesafekeeper may be required to stake an amount of currency/tokenizedtokens equal or proportionate to the appraised value of the collateralitem as a safeguard in case the item is lost or damaged duringsafekeeping (or may provide proof of insurance). In embodiments, thesafekeeping smart contract instance may then provide a notification tothe loan process smart contract instance indicating that the item hasbeen safely stored in escrow, where the notification may include a hashvalue of the safekeeping report and any other supporting evidence and/ora block address to the safekeeping report and the supporting evidence.In response to the notification, the loan process smart contract mayadvance the loan process to a tokenization stage 2910.

During the tokenization stage 2910, the tokenization platform 100 (oranother suitable component) may generate tokenize the collateral item.In embodiments, the tokenization platform 100 may generate a VIRL of thecollateral item based on data that describes and/or depicts thecollateral item, such as descriptions, images, videos, 2D scans, and/or3D scans of the collateral item. In embodiments, the borrower, thesafekeeper, and/or the authenticator may provide the data used togenerate the VIRL. In embodiments, the tokenization platform 100generates a collateral token of the item based on the VIRL of thecollateral item. Once an item is tokenized, the tokenization platform100 may write the token to the distributed ledger 2016 and may initiallyassign the ownership rights to the collateral token to the borrower(until a loan agreement is reached). Once the collateral item has beentokenized, the tokenization platform 100 may provide a notification tothe loan process smart contract 2022 indicating the tokenization eventand/or an address of the collateral token. Upon receiving notificationof tokenization event, the loan process smart contract 2022 may advancethe loan process to a lending stage 2912.

During the lending stage 2912, the borrower may request a loan and/ormay negotiate a loan with one or more lenders. Upon receivingconfirmation that the lender and borrower have agreed to loan terms, theloan process smart contract 2022 may instantiate a loan smart contract2034 in accordance with the agreed upon terms of the loan. In someembodiments, the tokenization platform 100 may provide a GUI to aborrower that allows the borrower to request a loan from one or morepotential lenders and/or negotiate a loan agreement with the one or morelenders. It is appreciated that in some embodiments, the loannegotiation may be handled on-chain rather than via a centralizedservice, such as the tokenization platform 100. In embodiments, theborrower may request a loan amount that does not exceed the appraisedvalue and a proposed loan term that indicates an amount of time to payback the loan. In some of these embodiments, the tokenization platform100 may generate a loan request that is presented to potential lendersvia a GUI, whereby the loan request indicates the sought amount, thelength of the loan, and information relating to the collateral itemprovided by the borrower (e.g., a VIRL of the collateral item,authentication reports, appraisal reports, safekeeping reports,verification that the authentication, appraisal, and safekeepers havesecured their respective tasks (as described above), and/or the like).In embodiments, the tokenization system 100 may suggest a loan repaymentamount and/or an interest rate (e.g., based on current marketconditions) for the loan. Alternatively, a potential lender may providean interest rate or a total repayment amount that the borrower wouldhave to pay back via the GUI. Additionally, the potential lender maycounter one or more of the requested loan terms, such as the loan amountand/or the repayment period. The loan offer may then be communicated toa borrower via a GUI, where the borrower may view the loan offer via aborrower device 2002. In response, the borrower may accept the loanoffer, reject the loan offer, or provide a counteroffer. The parties mayiterate in the manner until an agreement is reached or one or bothparties reject the loan offer. Upon a loan being reached, the partiesmay execute the loan agreement and the tokenization platform 100 mayprovide a notification to the loan process smart contract instanceindicating that a loan agreement has been agreed to by the borrower anda lender. In embodiments, the notification may include the details ofthe loan agreement including the terms of the loan agreement. Inresponse, the loan process smart contract instance may instantiate aloan smart contract instance that executes a loan repayment workflow.Once a loan agreement is executed, the loan smart contract may lock thecollateral token in an escrow account and may facilitate the transfer ofthe funds from an account of the lender to an account of the borrower.In embodiments, the loan agreement, records of any offers/counteroffers,and records relating to the escrowing of the collateral token and thetransfer funds to the borrower may be written to a distributed ledger2016. Once the loan process smart contract instance receivesnotification that the collateral token has been locked and the fundshave been transferred, the loan process smart contract instance mayadvance the loan process to the repayment stage 2914.

During the repayment stage 2914, the loan smart contract instance maymonitor the borrowers payment history to ensure that payments are madeby the borrower to the lender (or an account that distributes paymentsto the lender) in accordance with a loan schedule and that the loan isnot in a default condition. During the loan repayment stage, theborrower may remit payments. Each time a payment is made, the loanprocess smart contract instance may receive a payment notificationindicating that a payment has been made and an amount of the payment.The loan smart contract instance may then determine whether the loan hasbeen repaid in full. If the loan has not been paid in full, the loansmart contract instance may adjust the loan repayment amount and mayperform additional operations, such as returning some of the stakedfunds from the authenticators, appraisers, and/or safekeepers to reflectthe new loan repayment amount. If the loan smart contract instancedetermines that the loan repayment amount has been paid in full, theloan smart contract instance may send a repayment notification to theloan process smart contract instance indicating that the loan has beenpaid in full and may advance the loan process to the post-loan stage2916. In embodiments, the repayment notification may include hash valuesof payment event records indicating that payments were made and theamount of the payments and/or addresses of the payment records on thedistributed ledger 2016. Conversely, if the loan smart contract instancedetermines that the borrower defaulted, the loan smart contract mayinstance may trigger a liquidation event and/or send a defaultnotification to the loan process smart contract indicating that the loanis in default in accordance with the terms of the loan. In embodimentsthe default notification may include hash values of a default eventrecord indicating which payments were missed and the remaining balanceon the loan and/or addresses of the default event record on thedistributed ledger 2016. In response to receiving a defaultnotification, the loan smart contract instance may initiate a liquationevent and may advance the loan process to the post-loan stage 2916.

During the post-loan stage 2916, the collateral token is either returnedto the owner if the loan has been fully paid or a liquidation event isconducted. In response to receiving a repayment notification that theloan has been repaid in full, the loan smart contract instance mayinitiate the transfer of the collateral token from the escrow account toan account of the borrower, who may then redeem the collateral token toobtain possession of the collateral item. Once the loan has beensuccessfully repaid, the loan process smart contract instance mayinitiate the awarding of rewards to accounts of the authenticator,appraiser, and safekeeper (e.g., from the funds that were paid back tothe lender) in accordance with the terms set forth in the authenticationsmart contract, the appraisal smart contract, and the safekeepingcontract.

In initiating a liquidation event, the loan smart contract instance maysend an address of the collateral token to an appropriate marketplace(e.g., marketplace system 102), which may liquidate the collateral item(e.g., in an auction). During the liquidation event, a buyer maypurchase the collateral token, which results in the ownership data 2054of the collateral token being assigned to the buyer, who may then redeemthe collateral token to obtain possession of the collateral item. Onceliquidated, the loan process smart contract instance may distribute theremainder of the outstanding balance to the lender (or a secondarylender if the loan was sold to a secondary lender) from the proceeds ofthe liquidation event. After the liquidation event, the loan processsmart contract instance may initiate the awarding of rewards to accountsof the authenticators, appraisers, and safekeeper from the proceeds ofthe liquidation event in accordance with the terms set forth in theauthentication smart contract, the appraisal smart contract, and thesafekeeping contract. To the extent any balance remains, the remaindermay be credited to the account of the borrower.

Once the loan process is complete, the loan process smart contractinstance may notify the tokenization platform 100 that the loan processhas been completed, and the tokenization platform 100 may run ananalytics processes based on the completed loan process. In someembodiments, the results of the loan process may be used to update theratings of one or more of the authenticators, the appraisers, thesafekeeper, the lender, and/or the borrower.

It is appreciated that the foregoing is an example of a decentralizedloan process workflow 2900 and that alternative workflows may beexecuted. Furthermore, the decentralized loan process workflow 2900 mayinclude additional or alternative steps that were not explicitlydiscussed.

FIG. 30 illustrates an example of loan process workflow 3000 accordingto some embodiments of the present disclosure. In the example loanprocess workflow 3000 a pre-loan liquidation event is conducted beforethe loan terms are agreed to. During an example pre-loan liquidationstage, a marketplace (e.g., a marketplace hosted by or in communicationwith the marketplace system 102 of the tokenization platform 100) maysell a collateral item to a contingent buyer at a set price or auctionoff the collateral item to the contingent buyer prior to the negotiationand/or execution of a loan involving the collateral item with a set ofcontingencies. In embodiments, the set of contingencies may include apossession contingency and a reward contingency. In embodiments, apossession contingency conditions the contingent buyer's possessionrights to the collateral item upon a confirmed default event withrespect to a loan agreement entered into by the borrower that is securedby the collateral item. Put another way, the contingent buyer would onlybe able to take possession of the collateral item (e.g., by redeeming acorresponding collateral item) if the borrower was able to secure a loanusing the collateral item as collateral and the borrower later defaultedon that loan. In embodiments, a reward contingency may condition theawarding of a reward (e.g., an amount of currency/tokenized tokens orfiat currency) to the contingent buyer (e.g., by depositing the rewardinto an electronic account thereof) if the borrower successfully repaysthe loan. In this way, the contingent buyer is incentivized to purchasecollateral items on a contingency, as he or she will be rewarded if theloan is successfully repaid. Put another way, the contingent buyer maybe provided a monetary reward in exchange for agreeing to set aliquidation price of a collateral item before a loan is entered into bythe current owner of the collateral item (i.e., the borrower). It isnoted that in some embodiments, a borrower may agree to sell thecollateral item to the contingent buyer and forego the opportunity toseek out a loan after the pre-loan liquidation stage. The pre-loanliquidation stage may be performed in place of an appraisal stage or maybe requested after the appraisal stage (e.g., by a borrower and/orlender if one or more both of the parties do not agree to the appraisedvalue of the collateral item).

In the example of FIG. 30, the loan process workflow 3000 may include: arequest stage 3002 where the borrower requests to begin a loan process;followed by an authentication stage 3004 where one or moreauthenticators authenticate a collateral item; followed by a safekeepingstage 3006 where the authenticated item is stored in escrow with atrusted safekeeper; followed by a tokenization stage 3010 where a VIRLcorresponding to the collateral item is generated and tokenized into acollateral token; followed by a pre-loan liquidation stage 3006 wherethe authenticated items are conditionally sold via a marketplace to seta liquidation value of the collateral item before the loan terms arenegotiated; followed by a lending stage 3012 where a loan is negotiatedand accepted by the borrower and a lender; followed by a repayment stage3014 where the loan is repaid by the borrower; and followed by apost-loan stage 3016 where the collateral token is unlocked and returnedto the borrower or liquidated if the borrower defaults on the loan andany rewards are issued to the participants of the loan process.

During the request stage 3002, a borrower may request to begin a newloan process that includes collateralizing an item owned by theborrower. In embodiments, the borrower may request the loan via aborrower device 2002 that interfaces with the tokenization platform 100.In these embodiments, the tokenization platform 100 (or another suitablesystem) may provide a GUI where the borrower may provide informationsuch as a collateral item to be collateralized, a location of thecollateral item, a loan amount sought, and/or a proposed loan term. Inresponse to the borrower request, the tokenization platform 100 mayinstantiate a loan process smart contract instance. In embodiments, theloan process smart contract instance may determine a type of thecollateral item (e.g., from the request provided by the borrower) andmay request an authenticator (and potentially secondary authenticators)to authenticate the collateral item, thereby progressing the loanprocess to the authentication stage 3004.

During the authentication stage 3004, the loan process smart contractinstance may instantiate an instance of an authentication smart contract2028. In embodiments, the tokenization platform 100 may assign anauthentication task to a primary authenticator (and potentiallysecondary authenticators) from an authentication guild that specializesin authenticating items such as the collateral item, as described above.In embodiments, the primary authenticator may confirm receipt of theitem to be authenticated via an authenticator device 2004. Inembodiments, the authenticator may generate an authentication reportindicating a determination to the authenticity of the collateral item,as well as any supporting documentation. In embodiments, theauthentication report and supporting evidence may be provided to one ormore secondary authenticators, who in turn may validate theauthentication report and may provide additional supportingdocumentation. In embodiments, the authentication report and anysupporting documentation may be written to a distributed ledger 2016. Insome embodiments, the authenticators that participated in theauthentication task may be required to stake an amount ofcurrency/tokenized tokens as a safeguard in case the item is liquidatedand later deemed fake. In example embodiments, the loan process smartcontract 2022 may include a listening thread that listens for anauthentication notification issued by the instantiated authenticationsmart contract 2028 indicating whether the item was authentic or deemedfake by the authenticator(s), where the notification from theauthentication smart contract 2028 may include the opinion of theauthenticators (e.g., fake or authentic), a hash value of theauthentication report and any other supporting evidence, and/or a blockaddress to the authentication report and the supporting evidence. If theloan process smart contract instance determines that the item was deemedauthentic, the loan process smart contract instance may advance the loanprocess to a safekeeping stage 3006.

During the safekeeping stage 3006, the loan process smart contractinstance may request a safekeeper to safekeep the collateral item andmay instantiate an instance of a safekeeping smart contract 2032, whichexecutes a safekeeping workflow. In embodiments, the tokenizationplatform 100 may assign a safekeeper to the safekeeping task, forexample, based on the type of collateral item and/or the safekeeper'sproximity to the collateral item. Once the safekeeper has confirmedreceipt of the item, the safekeeper may generate a safekeeping reportthat indicates that the item is stored and notes any damage to thecollateral item at the time it was received and inspected, as well asany supporting documentation that supports the safekeeping report. Inembodiments, the safekeeping report and any supporting documentation maybe written to a distributed ledger 2016. In some embodiments, thesafekeeper may be required to stake an amount of currency/tokenizedtokens equal or proportionate to an approximate value of the collateralitem as a safeguard in case the item is lost or damaged duringsafekeeping (or may provide proof of insurance). In embodiments, thesafekeeping smart contract instance may then provide a notification tothe loan process smart contract instance indicating that the item hasbeen safely stored in escrow, where the notification may include a hashvalue of the safekeeping report and any other supporting evidence and/ora block address to the safekeeping report and the supporting evidence.In response to the notification, the loan process smart contract mayadvance the loan process to a tokenization stage 3008.

During the tokenization stage 3008, the tokenization platform 100 (oranother suitable component) may generate tokenize the collateral item.In embodiments, the tokenization platform 100 may generate a VIRL of thecollateral item based on data that describes and/or depicts thecollateral item, such as descriptions, images, videos, 2D scans, and/or3D scans of the collateral item. In embodiments, the borrower, thesafekeeper, and/or the authenticator may provide the data used togenerate the VIRL. In embodiments, the tokenization platform 100generates a collateral token of the item based on the VIRL of thecollateral item. Once an item is tokenized, the tokenization platform100 may write the token to the distributed ledger 2016 and may initiallyassign the ownership rights to the collateral token to the borrower(until a loan agreement is reached). Once the collateral item has beentokenized, the tokenization platform 100 may provide a notification tothe loan process smart contract 2022 indicating the tokenization eventand/or an address of the collateral token. Upon receiving notificationof tokenization event, the loan process smart contract 2022 may advancethe loan process to a pre-loan liquidation stage 3010.

During the pre-loan liquidation stage 3010, the loan process smartcontract instance may instantiate an instance of a pre-loan liquidationsmart contract. In embodiments, the pre-loan liquidation smart contractinstance may provide a pre-loan liquidation request to a marketplace(e.g., marketplace system 102). In embodiments, the request may includethe VIRL (or an indicator thereof, such as a VIRL ID or the like) and/orother documentation describing and/or showing the collateral item. Inembodiments, the contingent sale request may include other suitableinformation, such as a contingent sale type (e.g., auction or set pricesale), a location of the collateral item, a sought price for thecollateral item (if a set price sale), a minimum price for thecollateral item (if an auction), a length of the contingency (e.g., theamount of time that the borrower needs to secure and repay the loan), areward offer (e.g., a predefine reward amount or a percentage of thepurchase price, desired loan amount, or repayment amount), and/or thelike. In response the marketplace can facilitate a contingent sale,which may result in the collateral item being sold (e.g., a contingentbuyer buys the collateral item at a set price or wins an auction) with aset of contingencies or no sale. In embodiments, the pre-loanliquidation smart contract may receive the results of the contingentsale from the marketplace. Once the contingent sale is completed, themarketplace can send a sale notification to the liquidation smartcontract instance indicating the results of the pre-loan liquidationevent. In embodiments, the results of the pre-loan liquidation eventindicate whether the item was sold, and if sold, a price at which theitem was sold (minus any fees taken by the marketplace for hosting thesale). At this juncture, the pre-loan liquidation smart contract mayprovide a contingent sale notification to a borrower device 2002 of theborrower (assuming a pre-loan sale of the collateral item occurred) andthe borrower may a) agree to the contingent sale to advance the loanprocess, b) refuse the contingent sale and end the loan process (e.g.,if the sale was an auction and the agreed upon liquidation price was toolow to secure a loan), or c) decide to complete the contingent sale andend the loan process. If the borrower agrees to complete the contingentsale, the pre-loan liquidation smart contract may initiate the transferof the collateral token 2042 to the contingent buyer and the transfer ofthe proceeds of the sale to the buyer (e.g., a purchase amount incurrency/tokenized tokens or fiat currency) minus any fees taken by themarketplace. In the event that the borrower agrees to the contingentsale, the pre-loan liquidation smart contract instance may lock thecollateral item in an escrow account. Additionally, the pre-loanliquidation smart contract instance may escrow the proceeds of the salefrom the contingent buyer (or a portion thereof) in an escrow account toensure that the contingent buyer can pay the sale price should the loango into default. The pre-loan liquidation smart contract instance maywrite a pre-loan liquidation event record to the distributed ledger andmay issue a notification to the loan process smart contract instancethat indicates that the conditional sale was completed and a pre-loanliquidation price of the collateral item. In response, the loan processsmart contract instance may advance the loan process to a lending stage3012.

During the lending stage 3012, the borrower may request a loan and/ormay negotiate a loan with one or more lenders. Upon receivingconfirmation that the lender and borrower have agreed to loan terms, theloan process smart contract 2022 may instantiate a loan smart contract2034 in accordance with the agreed upon terms of the loan. In someembodiments, the tokenization platform 100 may provide a GUI to aborrower that allows the borrower to request a loan from one or morepotential lenders and/or negotiate a loan agreement with the one or morelenders. It is appreciated that in some embodiments, the loannegotiation may be handled on-chain rather than via a centralizedservice, such as the tokenization platform 100. In embodiments, theborrower may request a loan amount that does not exceed the pre-loanliquidation sale value and a proposed loan term that indicates an amountof time to pay back the loan. In some of these embodiments, thetokenization platform 100 may generate a loan request that is presentedto potential lenders via a GUI, whereby the loan request indicates thesought amount, the length of the loan, and information relating to thecollateral item provided by the borrower (e.g., a VIRL of the collateralitem, authentication reports, pre-sale liquidation reports, safekeepingreports, verification that the authentication, appraisal, andsafekeepers have secured their respective tasks (as described above),and/or the like). In embodiments, the tokenization system 100 maysuggest a loan repayment amount and/or an interest rate (e.g., based oncurrent market conditions) for the loan. Alternatively, a potentiallender may provide an interest rate or a total repayment amount that theborrower would have to pay back via the GUI. Additionally, the potentiallender may counter one or more of the requested loan terms, such as theloan amount and/or the repayment period. The loan offer may then becommunicated to a borrower via a GUI, where the borrower may view theloan offer via a borrower device 2002. In response, the borrower mayaccept the loan offer, reject the loan offer, or provide a counteroffer.The parties may iterate in the manner until an agreement is reached orone or both parties reject the loan offer. Upon a loan being reached,the parties may execute the loan agreement and the tokenization platform100 may provide a notification to the loan process smart contractinstance indicating that a loan agreement has been agreed to by theborrower and a lender. In embodiments, the notification may include thedetails of the loan agreement including the terms of the loan agreement.In response, the loan process smart contract instance may instantiate aloan smart contract instance that executes a loan repayment workflow.Once a loan agreement is executed, the loan smart contract may lock thecollateral token in an escrow account and may facilitate the transfer ofthe funds from an account of the lender to an account of the borrower.In embodiments, the loan agreement, records of any offers/counteroffers,and records relating to the escrowing of the collateral token and thetransfer funds to the borrower may be written to a distributed ledger2016. Once the loan process smart contract instance receivesnotification that the collateral token has been locked and the fundshave been transferred, the loan process smart contract instance mayadvance the loan process to the repayment stage 3014.

During the repayment stage 3014, the loan smart contract instance maymonitor the borrowers payment history to ensure that payments are madeby the borrower to the lender (or an account that distributes paymentsto the lender) in accordance with a loan schedule and that the loan isnot in a default condition. During the loan repayment stage, theborrower may remit payments. Each time a payment is made, the loanprocess smart contract instance may receive a payment notificationindicating that a payment has been made and an amount of the payment.The loan smart contract instance may then determine whether the loan hasbeen repaid in full. If the loan has not been paid in full, the loansmart contract instance may adjust the loan repayment amount and mayperform additional operations, such as returning some of the stakedfunds from the authenticators and/or safekeeper to reflect the new loanrepayment amount. If the loan smart contract instance determines thatthe loan repayment amount has been paid in full, the loan smart contractinstance may send a repayment notification to the loan process smartcontract instance indicating that the loan has been paid in full and mayadvance the loan process to the post-loan stage 2716. In embodiments,the repayment notification may include hash values of payment eventrecords indicating that payments were made and the amount of thepayments and/or addresses of the payment records on the distributedledger 2016. Conversely, if the loan smart contract instance determinesthat the borrower defaulted, the loan smart contract may transmit adefault notification to the loan process smart contract indicating thatthe loan is in default in accordance with the terms of the loan. Inembodiments the default notification may include hash values of adefault event record indicating which payments were missed and theremaining balance on the loan and/or addresses of the default eventrecord on the distributed ledger 2016. In response to receiving adefault notification, the loan smart contract instance may provide adefault notification to the loan process smart contract instance and/orthe pre-loan liquidation event smart contract to initiate the transferof the collateral token 2042 to the contingent buyer. Upon a defaultcondition being determined, the loan process may advance to thepost-loan stage 3016.

During the post-loan stage 3016, the collateral token 2042 is eitherreturned to the owner if the loan has been fully paid or the collateraltoken 2042 is transferred to the contingent buyer pursuant to thepossession contingency. In response to receiving a repaymentnotification that the loan has been repaid in full, the loan smartcontract instance may initiate the transfer of the collateral token fromthe escrow account to an account of the borrower, who may then redeemthe collateral token to obtain possession of the collateral item. Oncethe loan has been successfully repaid, the loan process smart contractinstance may initiate the awarding of rewards to accounts of theauthenticator, contingent buyer pursuant to the reward contingency, andsafekeeper (e.g., from the funds that were paid back to the lender) inaccordance with the terms set forth in the authentication smartcontract, the pre-loan liquidation smart contract, and the safekeepingcontract.

In the case of a default condition, the loan contract instance mayprovide a default notification to the loan process smart contract andthe pre-loan liquidation smart contract. In response to receiving thedefault condition, the pre-loan liquidation smart contract may unlockthe funds that were escrowed from the contingent buyer during thepre-loan liquidation event. The loan process smart contract instance maydistribute the outstanding balance on the loan repayment amount to thelender (or a secondary lender if the loan was sold to a secondarylender) from the proceeds of the pre-loan liquidation event (e.g., theunlocked funds from the contingent buyer as well as any remainingbalance owed by the contingent buyer). Upon confirming that thecontingent buyer has no outstanding balance form the pre-liquidationsale, the pre-loan liquidation smart contract instance may unlock thecollateral token 2042 from escrow and may transfer the collateral token2042 to an account of the contingent buyer, who may then redeem thecollateral token to take possession of the collateral item.Additionally, the loan process smart contract instance may initiate theawarding of rewards to accounts of the authenticators and safekeeperfrom the proceeds of the pre-loan liquidation event in accordance withthe terms set forth in the authentication smart contract and thesafekeeping contract. To the extent any balance remains, the remaindermay be credited to the account of the borrower.

Once the loan process is complete, the loan process smart contractinstance may notify the tokenization platform 100 that the loan processhas been completed, and the tokenization platform 100 may run ananalytics processes based on the completed loan process. In someembodiments, the results of the loan process may be used to update theratings of one or more of the authenticators, the safekeeper, thecontingent buyer, the lender, and/or the borrower.

It is appreciated that the foregoing is an example of a decentralizedloan process workflow 3000 and that alternative workflows may beexecuted. Furthermore, the decentralized loan process workflow 3000 mayinclude additional or alternative steps that were not explicitlydiscussed. It is noted that order of some of the stages of the loanprocess workflow 3000 may varied to achieve certain efficiencies. Forexample, if the collateral item is difficult to ship and/or isperishable, the safekeeping stage and tokenization stage may beperformed prior to the authentication stage.

While only a few embodiments of the present disclosure have been shownand described, it will be obvious to those skilled in the art that manychanges and modifications may be made thereunto without departing fromthe spirit and scope of the present disclosure as described in thefollowing claims. All patent applications and patents, both foreign anddomestic, and all other publications referenced herein are incorporatedherein in their entireties to the full extent permitted by law.

The methods and systems described herein may be deployed in part or inwhole through a machine that executes computer software, program codes,and/or instructions on a processor. The present disclosure may beimplemented as a method on the machine, as a system or apparatus as partof or in relation to the machine, or as a computer program productembodied in a computer readable medium executing on one or more of themachines. In embodiments, the processor may be part of a server, cloudserver, client, network infrastructure, mobile computing platform,stationary computing platform, or other computing platforms. A processormay be any kind of computational or processing device capable ofexecuting program instructions, codes, binary instructions and the like,including a central processing unit (CPU), a general processing unit(GPU), a logic board, a chip (e.g., a graphics chip, a video processingchip, a data compression chip, or the like), a chipset, a controller, asystem-on-chip (e.g., an RF system on chip, an AI system on chip, avideo processing system on chip, or others), an integrated circuit, anapplication specific integrated circuit (ASIC), a field programmablegate array (FPGA), an approximate computing processor, a quantumcomputing processor, a parallel computing processor, a neural networkprocessor, or other type of processor. The processor may be or mayinclude a signal processor, digital processor, data processor, embeddedprocessor, microprocessor or any variant such as a co-processor (mathco-processor, graphic co-processor, communication co-processor, videoco-processor, AI co-processor, and the like) and the like that maydirectly or indirectly facilitate execution of program code or programinstructions stored thereon. In addition, the processor may enableexecution of multiple programs, threads, and codes. The threads may beexecuted simultaneously to enhance the performance of the processor andto facilitate simultaneous operations of the application. By way ofimplementation, methods, program codes, program instructions and thelike described herein may be implemented in one or more threads. Thethread may spawn other threads that may have assigned prioritiesassociated with them; the processor may execute these threads based onpriority or any other order based on instructions provided in theprogram code. The processor, or any machine utilizing one, may includenon-transitory memory that stores methods, codes, instructions andprograms as described herein and elsewhere. The processor may access anon-transitory storage medium through an interface that may storemethods, codes, and instructions as described herein and elsewhere. Thestorage medium associated with the processor for storing methods,programs, codes, program instructions or other type of instructionscapable of being executed by the computing or processing device mayinclude but may not be limited to one or more of a CD-ROM, DVD, memory,hard disk, flash drive, RAM, ROM, cache, network-attached storage,server-based storage, and the like.

A processor may include one or more cores that may enhance speed andperformance of a multiprocessor. In embodiments, the process may be adual core processor, quad core processors, other chip-levelmultiprocessor and the like that combine two or more independent cores(sometimes called a die).

The methods and systems described herein may be deployed in part or inwhole through a machine that executes computer software on a server,client, firewall, gateway, hub, router, switch,infrastructure-as-a-service, platform-as-a-service, or other suchcomputer and/or networking hardware or system. The software may beassociated with a server that may include a file server, print server,domain server, internet server, intranet server, cloud server,infrastructure-as-a-service server, platform-as-a-service server, webserver, and other variants such as secondary server, host server,distributed server, failover server, backup server, server farm, and thelike. The server may include one or more of memories, processors,computer readable media, storage media, ports (physical and virtual),communication devices, and interfaces capable of accessing otherservers, clients, machines, and devices through a wired or a wirelessmedium, and the like. The methods, programs, or codes as describedherein and elsewhere may be executed by the server. In addition, otherdevices required for execution of methods as described in thisapplication may be considered as a part of the infrastructure associatedwith the server.

The server may provide an interface to other devices including, withoutlimitation, clients, other servers, printers, database servers, printservers, file servers, communication servers, distributed servers,social networks, and the like. Additionally, this coupling and/orconnection may facilitate remote execution of programs across thenetwork. The networking of some or all of these devices may facilitateparallel processing of a program or method at one or more locationswithout deviating from the scope of the disclosure. In addition, any ofthe devices attached to the server through an interface may include atleast one storage medium capable of storing methods, programs, codeand/or instructions. A central repository may provide programinstructions to be executed on different devices. In thisimplementation, the remote repository may act as a storage medium forprogram code, instructions, and programs.

The software program may be associated with a client that may include afile client, print client, domain client, internet client, intranetclient and other variants such as secondary client, host client,distributed client and the like. The client may include one or more ofmemories, processors, computer readable media, storage media, ports(physical and virtual), communication devices, and interfaces capable ofaccessing other clients, servers, machines, and devices through a wiredor a wireless medium, and the like. The methods, programs, or codes asdescribed herein and elsewhere may be executed by the client. Inaddition, other devices required for the execution of methods asdescribed in this application may be considered as a part of theinfrastructure associated with the client.

The client may provide an interface to other devices including, withoutlimitation, servers, other clients, printers, database servers, printservers, file servers, communication servers, distributed servers andthe like. Additionally, this coupling and/or connection may facilitateremote execution of programs across the network. The networking of someor all of these devices may facilitate parallel processing of a programor method at one or more locations without deviating from the scope ofthe disclosure. In addition, any of the devices attached to the clientthrough an interface may include at least one storage medium capable ofstoring methods, programs, applications, code and/or instructions. Acentral repository may provide program instructions to be executed ondifferent devices. In this implementation, the remote repository may actas a storage medium for program code, instructions, and programs.

The methods and systems described herein may be deployed in part or inwhole through network infrastructures. The network infrastructure mayinclude elements such as computing devices, servers, routers, hubs,firewalls, clients, personal computers, communication devices, routingdevices and other active and passive devices, modules and/or componentsas known in the art. The computing and/or non-computing device(s)associated with the network infrastructure may include, apart from othercomponents, a storage medium such as flash memory, buffer, stack, RAM,ROM and the like. The processes, methods, program codes, instructionsdescribed herein and elsewhere may be executed by one or more of thenetwork infrastructural elements. The methods and systems describedherein may be adapted for use with any kind of private, community, orhybrid cloud computing network or cloud computing environment, includingthose which involve features of software as a service (SaaS), platformas a service (PaaS), and/or infrastructure as a service (IaaS).

The methods, program codes, and instructions described herein andelsewhere may be implemented on a cellular network with multiple cells.The cellular network may either be frequency division multiple access(FDMA) network or code division multiple access (CDMA) network. Thecellular network may include mobile devices, cell sites, base stations,repeaters, antennas, towers, and the like. The cell network may be aGSM, GPRS, 3G, 4G, 5G, LTE, EVDO, mesh, or other network types.

The methods, program codes, and instructions described herein andelsewhere may be implemented on or through mobile devices. The mobiledevices may include navigation devices, cell phones, mobile phones,mobile personal digital assistants, laptops, palmtops, netbooks, pagers,electronic book readers, music players and the like. These devices mayinclude, apart from other components, a storage medium such as flashmemory, buffer, RAM, ROM and one or more computing devices. Thecomputing devices associated with mobile devices may be enabled toexecute program codes, methods, and instructions stored thereon.Alternatively, the mobile devices may be configured to executeinstructions in collaboration with other devices. The mobile devices maycommunicate with base stations interfaced with servers and configured toexecute program codes. The mobile devices may communicate on apeer-to-peer network, mesh network, or other communications network. Theprogram code may be stored on the storage medium associated with theserver and executed by a computing device embedded within the server.The base station may include a computing device and a storage medium.The storage device may store program codes and instructions executed bythe computing devices associated with the base station.

The computer software, program codes, and/or instructions may be storedand/or accessed on machine readable media that may include: computercomponents, devices, and recording media that retain digital data usedfor computing for some interval of time; semiconductor storage known asrandom access memory (RAM); mass storage typically for more permanentstorage, such as optical discs, forms of magnetic storage like harddisks, tapes, drums, cards and other types; processor registers, cachememory, volatile memory, non-volatile memory; optical storage such asCD, DVD; removable media such as flash memory (e.g., USB sticks orkeys), floppy disks, magnetic tape, paper tape, punch cards, standaloneRAM disks, Zip drives, removable mass storage, off-line, and the like;other computer memory such as dynamic memory, static memory, read/writestorage, mutable storage, read only, random access, sequential access,location addressable, file addressable, content addressable, networkattached storage, storage area network, bar codes, magnetic ink,network-attached storage, network storage, NVME-accessible storage, PCIEconnected storage, distributed storage, and the like.

The methods and systems described herein may transform physical and/orintangible items from one state to another. The methods and systemsdescribed herein may also transform data representing physical and/orintangible items from one state to another.

The elements described and depicted herein, including in flow charts andblock diagrams throughout the figures, imply logical boundaries betweenthe elements. However, according to software or hardware engineeringpractices, the depicted elements and the functions thereof may beimplemented on machines through computer executable code using aprocessor capable of executing program instructions stored thereon as amonolithic software structure, as standalone software modules, or asmodules that employ external routines, code, services, and so forth, orany combination of these, and all such implementations may be within thescope of the present disclosure. Examples of such machines may include,but may not be limited to, personal digital assistants, laptops,personal computers, mobile phones, other handheld computing devices,medical equipment, wired or wireless communication devices, transducers,chips, calculators, satellites, tablet PCs, electronic books, gadgets,electronic devices, devices, artificial intelligence, computing devices,networking equipment, servers, routers and the like. Furthermore, theelements depicted in the flow chart and block diagrams or any otherlogical component may be implemented on a machine capable of executingprogram instructions. Thus, while the foregoing drawings anddescriptions set forth functional aspects of the disclosed systems, noparticular arrangement of software for implementing these functionalaspects should be inferred from these descriptions unless explicitlystated or otherwise clear from the context. Similarly, it will beappreciated that the various steps identified and described above may bevaried, and that the order of steps may be adapted to particularapplications of the techniques disclosed herein. All such variations andmodifications are intended to fall within the scope of this disclosure.As such, the depiction and/or description of an order for various stepsshould not be understood to require a particular order of execution forthose steps, unless required by a particular application, or explicitlystated or otherwise clear from the context.

The methods and/or processes described above, and steps associatedtherewith, may be realized in hardware, software or any combination ofhardware and software suitable for a particular application. Thehardware may include a general-purpose computer and/or dedicatedcomputing device or specific computing device or particular aspect orcomponent of a specific computing device. The processes may be realizedin one or more microprocessors, microcontrollers, embeddedmicrocontrollers, programmable digital signal processors or otherprogrammable devices, along with internal and/or external memory. Theprocesses may also, or instead, be embodied in an application specificintegrated circuit, a programmable gate array, programmable array logic,or any other device or combination of devices that may be configured toprocess electronic signals. It will further be appreciated that one ormore of the processes may be realized as a computer executable codecapable of being executed on a machine-readable medium.

The computer executable code may be created using a structuredprogramming language such as C, an object oriented programming languagesuch as C++, or any other high-level or low-level programming language(including assembly languages, hardware description languages, anddatabase programming languages and technologies) that may be stored,compiled or interpreted to run on one of the above devices, as well asheterogeneous combinations of processors, processor architectures, orcombinations of different hardware and software, or any other machinecapable of executing program instructions. Computer software may employvirtualization, virtual machines, containers, dock facilities,portainers, and other capabilities.

Thus, in one aspect, methods described above and combinations thereofmay be embodied in computer executable code that, when executing on oneor more computing devices, performs the steps thereof. In anotheraspect, the methods may be embodied in systems that perform the stepsthereof and may be distributed across devices in a number of ways, orall of the functionality may be integrated into a dedicated, standalonedevice or other hardware. In another aspect, the means for performingthe steps associated with the processes described above may include anyof the hardware and/or software described above. All such permutationsand combinations are intended to fall within the scope of the presentdisclosure.

While the disclosure has been disclosed in connection with the preferredembodiments shown and described in detail, various modifications andimprovements thereon will become readily apparent to those skilled inthe art. Accordingly, the spirit and scope of the present disclosure isnot to be limited by the foregoing examples, but is to be understood inthe broadest sense allowable by law.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosure (especially in the context of thefollowing claims) is to be construed to cover both the singular and theplural, unless otherwise indicated herein or clearly contradicted bycontext. The terms “comprising,” “with,” “including,” and “containing”are to be construed as open-ended terms (i.e., meaning “including, butnot limited to,”) unless otherwise noted. Recitations of ranges ofvalues herein are merely intended to serve as a shorthand method ofreferring individually to each separate value falling within the range,unless otherwise indicated herein, and each separate value isincorporated into the specification as if it were individually recitedherein. All methods described herein can be performed in any suitableorder unless otherwise indicated herein or otherwise clearlycontradicted by context. The use of any and all examples, or exemplarylanguage (e.g., “such as”) provided herein, is intended merely to betterilluminate the disclosure and does not pose a limitation on the scope ofthe disclosure unless otherwise claimed. The term “set” may include aset with a single member. No language in the specification should beconstrued as indicating any non-claimed element as essential to thepractice of the disclosure.

While the foregoing written description enables one skilled to make anduse what is considered presently to be the best mode thereof, thoseskilled in the art will understand and appreciate the existence ofvariations, combinations, and equivalents of the specific embodiment,method, and examples herein. The disclosure should therefore not belimited by the above described embodiment, method, and examples, but byall embodiments and methods within the scope and spirit of thedisclosure.

All documents referenced herein are hereby incorporated by reference asif fully set forth herein.

What is claimed is:
 1. A method comprising: receiving, by one or moreprocessing devices, a request to initiate a loan process from a userdevice, the request indicating a collateral item of a borrower; andexecuting, by the one or more processing devices, a loan process smartcontract instance that includes computer-readable instructions that areconfigured to manage a loan process in accordance with a loan processworkflow, wherein the loan process smart contract instance is configuredto: select the loan process workflow from a set of loan processworkflows, each workflow of the set of loan process workflows defining arespective order of smart contract-managed loan process stages; andexecute the selected loan process workflow, wherein each workflow in theset of loan process workflows includes: a collateral tokenization stagethat includes: generating a virtual representation of the collateralitem, wherein the virtual representation includes at least one of adescription of the collateral item and one or more media contents thatrespectively depict at least a portion of the collateral item; andgenerating, by the one or more processing devices, a collateral tokencorresponding to the collateral item, wherein the collateral token is adigital token that is stored on a distributed ledger and is redeemablefor the collateral item; cryptographically linking the collateral tokento the virtual representation of the collateral item; and assigning thecollateral token to a first user account of the borrower on thedistributed ledger; a loan negotiation stage that includes: receiving aloan agreement notification indicating a set of loan term parameters ofa loan agreement that was agreed to by a lender and the borrower,wherein the loan term parameters include a loan amount that the lenderwill receive, a set of repayment parameters, and a set of unlockingevents, wherein the set of unlocking events include a loan repaymentevent that defines a first set of electronically verifiable conditionsthat must be met to determine that the loan has been fully repaid and aloan default event that defines a second set of electronicallyverifiable conditions that must be met to determine that the borrowerhas defaulted on the loan; and a loan repayment stage that includes:locking the collateral token in an escrow account on the distributedledger until an unlocking event of the set of unlocking events isdetected, whereby the collateral token is prevented from being redeemedor assigned to another account while the collateral token remains lockedin the escrow account; monitoring a repayment status of the loan inaccordance with the loan term parameters to detect an occurrence of anyof the set of unlocking events; in response to detecting an occurrenceof the loan repayment event, unlocking the collateral token causing anunlocked token state wherein the borrower is no longer prevented fromredeeming or assigning the collateral token; in response to detecting anoccurrence of the loan default event, unlocking the collateral token andexecuting a liquidation workflow.
 2. The method of claim 1, wherein theselected loan process workflow includes a smart-contract managedauthentication stage, followed by a smart-contract managed appraisalstage, followed by a smart-contract managed safekeeping stage, whereinthe loan negotiation stage is triggered upon successful completion ofthe safekeeping stage.
 3. The method of claim 2, wherein the loannegotiation stage further includes: engaging with a plurality ofcandidate lenders to negotiate loan terms with the borrower bycommunicating at least a portion of the request including a soughtamount, a desired loan term, and information relating to the collateralitem; facilitating the negotiation of loan terms by enabling exchange ofoffers and counteroffers of loan terms between the borrower and thelender via a user interface presented to the borrower; monitoring theexchange of offers and counteroffers until a loan term negotiation eventis detected, wherein the loan term negotiation event signals acompletion of negotiation and is selected from a list of negotiationcompletion signals consisting of loan term agreement between theborrower and the lender and loan rejection by one or more of theborrower or the lender; and in response to detecting the completion ofnegotiation is signaled by a loan term agreement between the borrowerand the lender, preparing the loan agreement notification.
 4. The methodof claim 1, wherein the selected loan process workflow includes asmart-contract managed authentication stage, followed by asmart-contract managed conditional sale stage, followed by asmart-contract managed safekeeping stage, wherein the loan negotiationstage is triggered upon successful completion of the safekeeping stage.5. The method of claim 4, wherein the smart-contract managed conditionalsale stage includes initiating a pre-liquidation sale of the collateralitem via a digital marketplace, wherein the pre-liquidation sale of thecollateral item results in a buyer conditionally buying the collateralitem for a conditional sale price such that the buyer is granted thecollateral item should the borrower default on one or more loans thatare secured by the collateral item, wherein at least a portion of theconditional sale price of the collateral item is used to secure at leasta portion of the one or more loans that are secured by the collateralitem.
 6. The method of claim 1, wherein the selected loan processworkflow includes a smart-contract managed appraisal stage, followed bya smart-contract managed authentication stage, followed by asmart-contract managed safekeeping stage, wherein the loan negotiationstage is triggered upon successful completion of the safekeeping stage.7. The method of claim 6, wherein the selected loan process workflow isdefined in a system-level governance document that is stored on thedistributed ledger, and the system-level governance defines a conditionto initiate the safekeeping stage.
 8. The method of claim 1, wherein theselected loan process workflow includes a smart-contract managedsafekeeping stage, followed by the tokenization stage, followed by asmart-contract managed authentication stage, wherein the loannegotiation stage is triggered upon successful completion of theauthentication stage.
 9. The method of claim 6, wherein the loan amountthat the lender will receive is dependent on an appraisal of the item.10. The method of claim 1, wherein the loan process workflow includes asmart-contract managed authentication stage that includes anauthentication task that is performed by one or more authenticators toauthenticate the collateral item and signaling the loan negotiationstage to initiate loan negotiations between the borrower and the lenderupon confirming receipt of an authentication report generated by the oneor more authenticators.
 11. The method of claim 1, wherein the loanprocess workflow includes a smart-contract managed appraisal stage thatthat includes facilitating an appraisal task that is performed by one ormore appraisers to appraise the collateral item and issuing an appraisalnotification upon confirming an appraisal report indicating an appraisedvalue determined by the one or more appraisers, wherein the amount thatthe lender will receive is based at least in part on the appraisedvalue.
 12. The method of claim 1, wherein the loan process workflowincludes a safekeeping stage that includes managing a safekeeping taskof the collateral item by a safekeeper and issuing a safekeepingnotification upon confirming receipt of a safekeeper report from thesafekeeper of the safekeeping of the collateral item.
 13. The method ofclaim 1, wherein the loan process workflow includes a conditional salestage that includes: initiating a conditional sale of the collateraltoken via a digital marketplace, wherein the conditional sale of thecollateral item results in a conditional buyer buying a redemption rightto the collateral item that is triggered in response to the borrowerdefaulting on one or more loans that are secured by the collateral item,wherein at least a portion of the conditional sale price of thecollateral item is used to secure at least a portion of the one or moreloans that are secured by the collateral item.
 14. The method of claim1, wherein the loan process smart contract instance is executed at by aset of node devices that store the distributed ledger.
 15. The method ofclaim 1, wherein the collateral token is a digital token that is storedon a distributed ledger and is redeemable by an owner of the collateraltoken to take possession of the collateral item.
 16. The method of claim1, wherein to execute the selected loan process workflow includesinstantiating an appraisal smart contract instance that includescomputer readable instructions that are configured to facilitate anappraisal task that is performed by one or more appraisers to appraisethe collateral item and to issue an appraisal notification uponconfirming an appraisal report indicating an appraised value determinedby the one or more appraisers.
 17. The method of claim 1, wherein toexecute the selected loan process workflow includes instantiating anauthentication smart contract instance that includes computer readableinstructions that are configured to manage an authentication task thatis performed by one or more authenticators to authenticate thecollateral item and to issue an authentication notification uponconfirming receipt of an authentication report generated by the one ormore authenticators.
 18. The method of claim 1, wherein to execute theselected loan process workflow includes instantiating a safekeeper smartcontract instance that includes computer readable instructions that areconfigured to manage a safekeeping task of the collateral item by asafekeeper and to issue a safekeeping notification upon confirmingreceipt of a safekeeper report from the safekeeper of the safekeeping ofthe collateral item.
 19. The method of claim 1, wherein the loan processworkflow is defined in a system-level governance document that is storedon the distributed ledger, wherein the system-level governance defines acondition to initiate at least one loan process workflow stage selectedfrom a list of loan process workflow stages consisting of thecollateralization stage, the loan negotiation stage, and the loanrepayment stage.
 20. The method of claim 1, wherein the loan processsmart contract instance is further configured to: generate a data blockcontaining the virtual representation and the collateral token and acryptographic hash value that is generated based at least in part on thecollateral token; and write the data block to the distributed ledger.